Home to Microservices and WAS Liberty resources, which provide background information, getting started guidance, best practices, and methodologies.

Microservices! They are everywhere, or at least, the term is. When should you use a microservice architecture? What factors should be considered when making that decision? Do the benefits outweigh the costs? Why is everyone so excited about them, anyway?

The following collection of resources aim to answer those questions and more. Enjoy.

Historical Context: What problem are we trying to solve?

Enterprise applications, specifically Java EE applications deployed on traditional app servers, are usually deployed in tiers: the edge, the web front-end, the back-end, and shared databases. Business logic is monolithically deployed into these tiers (as one giant ear containing many wars, for example) with tight controls and centralized governance to reduce risk.

It is frustrating to have to coordinate application updates across business units and worry over scheduled maintenance windows. Iterative development and rapid response to marketplace feedback are impossible when it takes weeks to roll-out new function.

This is the challenge that microservices, as an application architecture, are trying to address. How do you decouple the delivery and deployment of new function or improved application experiences to more rapidly respond to the demands of the marketplace?

Concepts: What are microservices?

Martin Fowler provides the seminal description, and if you’ve not read his paper, you should. To quote:

the microservice architectural style … is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

Separating the bits of an application into pieces can be very freeing, and it is easy to appreciate from a quick skim how isolating each piece of the application would drastically reduce the overhead involved in making changes, and how it would dramatically reduce the risk around trying something new. But this approach does not come without pitfalls of its own: distributed application systems are not a trivial problem space to build in.

Related articles

Microservices and Cloud

Microservices does not mean Cloud and Cloud does not mean Microservices.

The Microservices application architecture aims to improve agility and productivity through separation of concerns and loose coupling. The approach is equally valid in or out of the Cloud; the benefits and challenges largely the same.

That said, Microservices and Cloud do make sense together. If you are deploying to Cloud, an application architecture based on independent, loosely coupled, stateless services can be a more natural fit for your target Cloud environment.

Related articles

  • IBM developerWorks Cloud Architecture Center

    • Twelve Factors

    Twelve-factor applications are a set of guidelines introduced by Heroku that do provide good guidance for creating the individual services that will compose your application. Most of these guidelines are design principles; others are about admin and operational concerns that may challenge conventional development culture – even requiring changes to how certain things get done where you live. It’s a good idea to think about such things up front so you can plan ahead.

    Related articles

    Managing Data

    For a successful microservices-based approach:

    • Keep all cross-service requests stateless (e.g. REST/HTTP and JSON), and build in fault-tolerance.
    • Control complexity by making sure that transactions never span service boundaries. Be sure to consider how to maintain consistency across partitioned data.

    One of the challenges for many microservice based applications – especially those deployed into Cloud environments – is access to existing data. Often this data is shared by existing applications and may not be easily accessible to your new Cloud hosted applications. The Redbook below offers some good solutions for how to bridge the divide.

    Related articles

    Security

    Security is an important consideration in a Microservices architecture, and key- or token-based authentication (OAuth2) is essential for both knowing who is calling a given service, and ensuring that only authorized parties (users or other services) have access.

    Related articles

    Logging and Metrics

    Logging and metrics are critical for maintaining a healthy infrastructure.

    Leverage technologies that collect and store logs, metrics and other problem determination information in a central location, where analytics tools can be applied to help identify patterns and troubleshoot problem areas in a large, complex topology.

    Related articles

    • Coming…

    Game On! A microservices app from scratch

    It’s both challenging and exciting to create a microservices application from scratch! We have some practical experience to share with you about an app we’re creating. We’re going to start writing about it very soon. So be sure to check back often to see how we’re doing.

    Related articles

    Monolith to Microservices: transforming an existing app

    When weighing the benefits versus the challenges of moving to a microservice architecture, don’t assume you must throw away your monolith. Instead, you’ll want to start slowly, extending your monolith by building new features as microservices around it. Eventually new replaces old, gradually eroding away your monolith. How far you take this is up to you – perhaps to the point the monolith is gone altogether.

    We invite you to journey with us on this adventure as we evolve an old favorite – Plants By WebSphere – from a traditional monolithic Java EE application into a microservice-based architecture. This is a work in progress, so we’ll continue to update this section as we go along. Check out the project on GitHub!

    The following blog posts and articles reflect in chronological order our on-going thought process and efforts around this evolution:

    Blog posts

    1. “Rules of Engagement” – Principles and Considerations (Adam Pilkington, wasdev.net)
    2. “Where do I start? – Revelations” (Adam Pilkington, wasdev.net)

    Related Articles

    1. Starting the evolution – decomposition and tools (Adam Pilkington, wasdev.net)
    2. First service (Image) and evolutionary stages (Adam Pilkington, wasdev.net)
    3. Implementing and testing Image service (Adam Pilkington, wasdev.net)
    4. Creating the image service for Plants by WebSphere using the Liberty app accelerator (Kate Stanley, wasdev.net)

    Hey! Be careful out there ☺

    So a microservices architecture offers lots of benefits. But let’s face it: there’s plenty of opportunity for trouble in the wild. One of the major risks is largely non-technical: pursuit of microservices architectures and 12 factor apps can challenge cultural norms. Failure to recognize and plan ahead for that can lead to failure. Check out the Clayton article below for some shared experience. On the technical side, microservices architectures are particularly susceptible to systemic performance and scale degradation due to designed-in network bottlenecks. The stackexchange discussion below sheds some helpful light on some of the issues.

    Important Resources

    Related articles

    Learn better by doing? Jump In!

    Related Presentations

    3 Comments on "Microservices and WAS Liberty"

    1. WASdev | Putting the 'Micro' into Microservices with Raspberry Pis - WASdev June 01, 2016

      […] Liberty and Microservices […]

      Reply
    2. WASdev | Explore Microservices via a text-based adventure May 04, 2016

      […] Microservices and WAS Liberty […]

      Reply
    3. Evolving Java EE applications to microservices: Costs and surprises - WASdev December 18, 2015

      […] mentioned this before in my “Rules of Engagement” – Principles and Considerations blog post, but it’s worth reading Martin Fowler’s Microservice Premium article. The […]

      Reply

    Join The Discussion

    Your email address will not be published. Required fields are marked *