"What's in a name?" is a famous quote by William Shakespeare. Well, let's see how true it is when it comes to one of the latest trends and buzz words in our industry: Microservices Architecture.
Taking a look at the name: microservices = Micro + Service, which literally means a very small service. This leads to the perception that it's just another service that does some menial task, although that may not be too far from the truth in some cases. However while the term microservices may be relatively new, its concepts and objectives have a history. To better understand and evaluate microservices, it's important to understand the different system architecture patterns that have come before.
Background: Monolithic and SOA Architectures
"In the beginning..." there was Monolithic Architecture. Monolithic applications are designed to include all layers (presentation, business logic, persistence/database access, and application integration) in a single software package (for example in the case of a web application, deployed in a single .war file). These application do not have clear distinction between data input and output, data processing, error handling, and the user interface. In fact, these are interwoven to the point that a change to one of the layer requires the entire application to go through a rebuild.
(Once the code base and the team starts growing, some of the advantages can start becoming hindrances)
Despite some of its challenges, a monolithic architecture can still be a valid approach and if your application works fine and you don't really want to do any refactoring, there is absolutely no need to change it.
Next came Services Oriented Architecture or SOA to try to address many of the challenges of monolithic approach. "A service-oriented architecture is a style of multi-tier computing that helps organizations share logic and data among multiple applications and usage modes." according to Gartner (Service Oriented" Architectures, Part 1).
SOA was envisioned to be light weight, loosely-coupled architecture and a byproduct of this was the notion of the Enterprise Service Bus (ESB). Many vendors productized this ESB concept but introduced proprietary standards and governance models. This resulted in complexity, bottlenecks and ultimately a heavy and expensive, highly-controlled architecture. Some vendors still continue branding and selling their product as an ESB but keep in mind it is an architecture design and you can pick and choose the functionality you like.
The Rise of Microservices
Because SOA could not live up to expectations as well as a rapid adoption of agile methodologies emphasizing things like continuous delivery and DevOps, the organization demanded new architecture. Enter microservices.
A microservices-based architecture is like a divide-and-conquer approach: the decomposition of the system into discrete and isolated subsystems communicating over well-defined interfaces protocols. Because both SOA and microservices are built around the concept of decoupled services, it's not surprising that some have labeled microservices as "SOA 2.0" or "Lighter SOA" (my personal favorite is "Hipster SOA").
Microservices are not necessarily defined by team size, number of lines of code, or number of API/endpoints but they do follow a general philosophy which includes:
- Many smaller, fine-grained, clearly-scoped services: The application is divided into smaller functionality, each having its own implementation, business logic, transformation logic own database. The idea is that if one of the service goes down, it should not affect the whole application. For example, for an e-commerce website, if "recommendation" service goes down, it should not bring down the entire site nor should it impact the checkout functionality.
- Single responsibility principle: Do just one thing, but do it Right. Use the right kind of people, framework, programming language, infrastructure and do it right.
- Clear ownership: Because the services are owned by individual teams, it's easy to identify ownership for enhancements and accountability.
- Independently managed (Devops): The adoption of DevOps has seen a significant increase, each service can be deployed independently.
Challenges and Solutions
GO for it!
There have been many success stories involving the implementation of microservices from major players in the industry including Amazon, eBay, Etsy, Spotify and Netflix just to name a few. Netflix supports their 50 million subscribers with 500 microservices and 30 engineering teams handling over two billion edge API requests/day. And of course there is the famous memo Amazon CEO Jeff Bezos sent to his company in the early 2000's mandating all teams must exchange data via microservices.
Boomi and Microservices
Now that we have looked at monolithic, SOA and microservices, the "$1M ACV question" is, how does Boomi fit into a microservices strategy?
More than two-thirds of Boomi customers use platform for real-time/event-driven and SOA-style integrations (ESB). During the introduction I spoke about how microservices are termed as SOA 2.0, "Hipster SOA". It should be clear by now, that microservices is SOA done right. Hence the already existing features of Boomi will definitely support microservice based architecture.
Some of the platform features that enable and support a microservices architecture include:
- API Management
- Dynamic Process Routing
- Atom Web Server
- Support for Docker
- Support for external load balancers
- Support for custom Authentication
- Support for industry protocols for inter-process communication
- Platform APIs
Are Microservices Right for You?
I would like to share my personal journey with microservices. When I started writing this blog, my notion was that I would be convinced that microservices was the best architecture and all applications going forward should follow this architecture. In my research I found that, in many organization and for many applications a monolithic architecture is a good fit and there is absolutely no need to change or refactor that architecture. Furthermore my reading concluded that there is a lot of disappointment around the promises that SOA could not deliver. I also learned there were many who felt the pain I have felt with "productized ESB". The misnomer that ESB is a product rather than an architecture has hurt SOA and ESB's reputations.
Finally, the more I read about microservices, the more I was convinced it is not a magic pill for all the other architecture pitfalls. It is promising and has been implemented in many big companies like Netflix, Amazon, Spotify with amazing results. These organizations have openly shared their experiences and best practices around microservices. Because organizations are trending towards agile methodologies, continuous delivery, and DevOps, microservices simply become an organic fit. Also, looking at the similarities between SOA and microservices, and the fact that more than two-third of our customers utilize Boomi for real-time/event-based integrations, goes to show that Boomi can support microservices architecture. In conclusion, microservices is another architecture design option and it is up to the individual architect to carefully examine the organization's culture and the given application before embarking on this route.
Is your organization and application ready for a microservices architecture?
If you're looking for even more microservices, here is some further reading:
- Microservices architecture
- Learn from SOA: 5 lessons for the microservices era | InfoWorld
- design - Difference between Microservices Architecture and SOA - Stack Overflow
- AWS re:Invent 2014 | (PFC304) Interprocess Comms in Cloud: Pros, Cons of Microservices Architectures - YouTube
Thameem Khan is an enterprise architect at Dell Boomi and has been instrumental in competitive positioning Dell Boomi to our Large enterprise customers. He is good at two things: manipulating data and connecting clouds.