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?
- Concepts: What are microservices?
- Microservices and Cloud
- Twelve Factors
- Managing Data
- Logging and Metrics
- Game On! A microservices app from scratch
- Monolith to Microservices: transforming an existing app
- Hey! Be careful out there ☺
- Important Resources
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.
- Microservices Architecture (Martin Fowler, martinfowler.com)
- Microservices in action, Part 1: Introduction to microservices (Rick Osowski, developerworks.com)
- Microservices: From Theory to Practice. Creating Applications in Bluemix Using the Microservices Approach (IBM Redbook)
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.
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.
- The 12-factor application (Adam Wiggins, 12factor.net)
- Creating a 12-factor application with WAS Liberty (Kate Stanley, wasdev.net)
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.
- Open Hybrid Cloud Data and API Integration: Integrate Your Enterprise and Cloud with Bluemix Integration Services (IBM Redbook).
- Sample cloud app demonstrating access to an on-premise database (Ram Vennam, github.com)
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.
- Using access tokens to secure microservices (Ozzy Osborne, wasdev.net)
- Using signed JSON Web Tokens (JWTs) to secure microservices (Ozzy Osborne, wasdev.net)
- Using API keys to secure your microservice (Adam Pilkington, wasdev.net)
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.
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.
- Game On! main page – check it out! (wasdev team, game-on.org)
- Reference Microservices Architecture
- Game On Architecture
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:
- “Rules of Engagement” – Principles and Considerations (Adam Pilkington, wasdev.net)
- “Where do I start? – Revelations” (Adam Pilkington, wasdev.net)
- Starting the evolution – decomposition and tools (Adam Pilkington, wasdev.net)
- First service (Image) and evolutionary stages (Adam Pilkington, wasdev.net)
- Implementing and testing Image service (Adam Pilkington, wasdev.net)
- 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.
- Integrate Your Enterprise and Cloud with Bluemix Integration Services (Redbook)
- Creating Applications in Bluemix Using the Microservices Approach (Redbook)
- A primer to WebSphere Liberty for Java EE developers
- Failing at Microservices (Richard Clayton, blog)
- How do microservice system architectures avoid network bottlenecks? (various, stackexchange)
- 4 reasons why WebSphere Liberty and Bluemix ease the lift and shift of on-premises microservices to the cloud (Vijay Bhadriraju, developerWorks)