Microservices are a VERY hot topic in technology architecture. In short, this architecture enables selective scaling and avoids the bloat of scaling an entire monolithic application. It is a hot topic because horizontal scaling is becoming one of the most important aspects in IoT, Web-Scale, and future streaming systems.
The benefits of microservices make many hearts beat faster. They promise grand, easily scaled functional components, enable better Continuous Delivery (CD) of a system and allow independent service upgrades, proper tooling for purpose, and more.
These benefits, however, don’t come without their cost (or architectural trade-offs). Thereare two essentials: Dev Ops and a truly agile platform with a high performing team. In some IT shops, versioning and other SDLC challenges get in the way of efficient management (systems, code, deployment, agile teams) that microservices require.
Although the concept of microservices is provocative (and every developer wants to build in this way), confusion surrounds the definition of microservices and the purposes for which it is – and is not – useful. Here’s my take on the subject. Please share yours.
Micros, minis and SOA
Let’s start with definitions. First and foremost, Microservices are a flavor of SOA. They are services and fit within a Service Oriented Architecture. Microservices are also exposed with proactive and purpose driven architecture, usually privately within a single application (or platform).
Just like “microservices,” the term “SOA” has also been open to (mis)interpretation in its history.
Service Oriented Architecture was the hot topic of its day when introduced in the early 2000s. Back then it was conceived that you could build a system with reusable “services” and abstract the top layers of your application. Thinking of data and specific business services in this way helped lead to exposing APIs like we do now (over the internet as opposed to within installed software). You could allow other companies to access your “services” for purposes that may have been tightly coupled previously. But simply exposing data with web services (or an API) is not SOA.
Some took the approach to mean that SOA was integration of data and exposed services that were only in the fashion of reusable integration points. This is one way to utilize a service, however the intent of SOA (in this man’s humble opinion) is to provide business and application level services (with business specific processing and data) to allow for consistency and reuse within application(s).
What, then, is a miniservice? This Gartner term is a topic of debate with my peers. However, I’ll try to explain because I do like the distinction (if just for calling out a distinction). A miniservice is true SOA (not unlike a microservice) that can include numerous microservices. It’s a level above microservices. It’s an external approach to services, while microservices focus on internal scale, ultimately improving external capabilities. I like the distinction, but isn’t an industry accepted term (as of yet).
Here’s the big difference: a microservice, being smaller and (spoiler alert) with its own data storage, can scale independently. A miniservice can scale with the application, but not necessarily on its own. Minis have (service)contracts with assets connecting and provide business logic (services) and data for Upserts, Archiving and Querying of data. The visual is one example of how to architect an SOA with microservices and miniservices, but not necessarily how it has to. Bottom line, they are all services.
Microservices drill-down
Microservices are designed with web-scale in mind, can be combined to provide access to a system via miniservice (or an API call) and all have individual scalability.
A well designed microservice has:
- Domain driven concepts
- Individualized scalability
- Small, very small, components with (in most cases) their own data storage (yeah, you read that right)
This requirement can lead to a number of management considerations and is essential to successful implementation. The team developing microservices has to be very high performing, with advanced agile concepts (DevOps, CI/CD, Versioning… etc.) all taking place in an efficient way. Individual Unit Testing tied to CI and CD are crucial for the architecture to succeed and produce all the potential benefits.
Microservices are focused on exposing data, not for re-use, but for scalability and high availability. Think about that for a minute (a data pump). SOA (historically) was designed for reuse of business components and services for enabling broader UI’s. Microservices are designed to reside within a single application (or platform) to scale to handle a jump in requests (volume). Microservices could also improve scalability of an exposed API or refactored service.
For example, look at the Stock Exchange. Trades happen very frequently, have to be consistent, and if one fails (messaging or other “glitch”), people lose money. So specific data transactions need to be highly scalable and highly available. Online brokerages manage this on their backend and have systems that scale.
Furthermore, user registration is nearly as important as a trade for brokerages. If registrations fail, they lose business. In a monolithic application, both the registration and trading components have to scale together, even though the volume of trading requests is likely to be far greater than for registration. It makes sense for brokerages to split these two, very different, services into miniservices that allow access to several microservices. In this way brokerages would gain flexibility in scale, make it easy to add features and save on server access, given that a specific part must scale, not the entire application.
As always, I would love to hear if you have a different opinion or method that has been successful in implementing microservices. If you’d like to engage with me please comment below or contact me via email (lsimon@summa-tech.com).
At Summa, we are working with a number of organizations on their enterprise-wide microservices strategy. These experiences along with our broad and deep expertise implementing traditional SOA, API’s and general enterprise wide architectures allows us a unique perspective on each individual case. We also bring our design approach, DevOps and Continuous Integration, and C2B Connector for Customer Engagement to help uncover innovative paths to success in your Architecture and Business Innovation Strategy.
