But what are microservices, precisely? Is an API a microservice? What are microservices good for? How do you manage them and most importantly: what value can they bring to your organization?
In this blog I will explain the high-level details of microservices, their value and how you can get started utilizing them. Be sure to check out our microservices white paper where you can find lots more valuable insights.
Looking for a definition
Without having a good definition, we could be talking across purposes. One of the best-known people in this area is Martin Fowler. According to him:
“There is no precise definition of this architectural style, there are certain common characteristics around organization around business capability, automated deployment, intelligence in the endpoints, and decentralized control of languages and data.”
Micro is not small
You might think that small as far as size goes also has something to do with microservices. However, this is not so much the case. What we can say is that they are smaller than the monolithic systems of the past but they’re not so small that they are almost at the lowest level. A microservice that is only able to Validate an iBAN number clearly does not qualify because it has no little business benefits of its own, it is part of something bigger in most cases. However, there are services online (APIs) that offer this service to other users online. This would qualify as an API, rather than a microservice.
So, what are the most important elements of a microservice? Let’s consider the four elements in bold from Martin Fowler’s comment.
Business capability
In case of a business capability what we’re doing is grouping in creating services around a major business process. For instance, in a bank this could be opening an account. In this case we are not looking at just storage or just the logic but basically everything that is needed in order to open the aforementioned account including user interface, storage collaborations, calculations, processes and so on. The whole registration process will obviously require the work of multiple microservices, for instance an account service, a customer service, a fraud service, a money laundering service, an identity verification service, and so on. And the process for a business account will be different from a consumer account.
Automated deployment
The process of building testing and deploying new microservices in an automated fashion does not only speed up the process it also reduces costs and improves the quality. The reason is that it eliminates human errors to a large extent (of course if the scripts do not have errors themselves). Continuous integration and continuous delivery are keywords in this sense together with all kinds of scripting tools. Containerization using e.g. Docker allows to quickly deploy microservices in their own environment and Kubernetes orchestration services allow to quickly scale up and down for that specific service on demand. To make it work throughout your pipeline, you just need to add some configuration management.
Decentralized control of languages and data
In building monolithic systems, we were trying to model the complete enterprise as a holistic blob. However, we found that these models became very big and almost impossible to manage. For microservices, each domain has its own so-called bounded context. This concept of domain driven design allows multiple of these bounded contexts mapped onto multiple microservices, each of which can have a unified model themselves. Rather than having one big database to store everything microservices might have their own databases that are using, retrieving information from others when needed.
Connecting services
Microservices are not tied to any specific language, framework or vendor. To assemble the system out of microservices, they must communicate over the network, typically over HTTP. There are many benefits of this communication style, such as scalability and reliability. Additionally, HTTP communication is available in any modern computer language, framework or middleware component. This versatility allows DevOps teams to choose the tooling that best fits their purpose and competence. Moreover, since its data is supposed to be enclosed in the microservice, database technology becomes also a tactical rather than strategic choice. For many microservices, disaggregation of databases plays out in favor of NoSQL-type storage technologies that store the data in a format close to how it gets processed. In the end, the account opening microservice we discussed will probably result in a traditional storage of a record, for instance in a regular RDBMS.
Smart endpoints
The Enterprise Service Bus allows you to do mediation and transformation in a layer of middleware in order to bridge two endpoints or services. In a microservice architecture, this centralization of control is considered hazardous. Intelligent endpoints try to overcome this by moving the integration logic closer to the endpoint, such that de DevOps team is in full control. Each DevOps team can make their own implementation choice, for instance using Ballerina, a MicroIntegrator, or in plain Go. Consequently, in case they have an integration failure, its blast radius will never exceed their own fiefdom.
What does all of that have to do with APIs ?
The answer is, quite a lot. Although not every API connects to a single microservice, microservices use APIs to communicate. So, building a microservice usually implies that you have an API as its interface to the outside world (event-driven and streaming microservices aside). Management of microservices, especially when they’re deployed in an environment like Docker or Kubernetes, needs to be paired with management of the interface to the microservice, to make sure that who calls the service is actually authorized to do that and does not exceed their quota.
Think API-First
A proper microservices design starts with API definitions (this is well before we even start building the service). APIs are the start, not the end.
This will help you discover your logical microservice boundaries. It will also help you evaluate who is consuming your services, and select an appropriate integration style (ReST, GraphQL or GRPC). Next, you should start discussing API Security (Security by Design). Early discussions on security will definitely help you build more solid microservices. Obviously, an API Gateway is a great tool to help you secure your services. At the same time, it is a centralization of control. In many situations, having a single point of access is actually a good thing. After all, digital logistics is not that different from physical logistics. In other situations, a more direct microservice-to-microservice interaction can be more appropriate. That’s where the API Microgateway comes in. This is an excellent choice to protect distributed architectures where it is most needed: at the heart. Especially when you adopt a self-contained JWT access token, you can eliminate every centralized point of control using the WSO2 API Microgateway.
If you look at a bigger scope, chances are there’s a place for both central and distributed API Gateways. They serve a different purpose, and very much complement each other. Fortunately, WSO2 is the one-stop-shop that provides both types, and also make them work together elegantly. You can share your API Traffic Manager, your API Key Manager, and your API Developer Portal. But it doesn’t end there. WSO2 API Manager Analytics is another great tool you can use across your entire hybrid service architecture.
How do I get started with microservices?
Although we have given you a lot of information, this is just the tip of the tip of the iceberg. If you’re looking for more of a deep-dive into microservices, I strongly suggest you read our white paper Microservices for the Enterprise. In this white paper, you will explore:
- Microservice architecture style
- How microservices are augmented by API management
- How thinking in API Zones will help to keep agility while offering manageability and control at the same time
- How microservices can be embedded into a larger integration architecture
Prepare for heterogeneity
Since your existing architecture is not going away anytime soon, a close alignment with the new microservice architecture is of vital importance. WSO2 and Yenlo can help you achieve just that. Developing your own hybrid strategy is perhaps my principal advice to help you succeed with microservices.
