To be successful implementing a microservice architecture, there are a number of related areas to consider as well. I will not cover these areas in this book; instead, I'll just briefly mention them here as follows:
- Importance of Dev/Ops: One of the benefits of a microservice architecture is that it enables shorter delivery times and, in extreme cases allows the continuous delivery of new versions. To be able to deliver that fast, you need to establish an organization where dev and ops work together under the mantra you built it, you run it. This means that developers are no longer allowed to simply pass new versions of the software over to the operations team. Instead, the dev and ops organizations need to work much more closely together, organized into teams that have full responsibility for the end-to-end life cycle of one microservice (or a group of related microservices). Besides the organizational part of dev/ops, the teams also need to automate the delivery chain, that is, the steps for building, testing, packaging, and deploying the microservices to the various deployment environments. This is known as setting up a delivery pipeline.
- Organizational aspects and Conway's law: Another interesting aspect of how a microservice architecture might affect the organization is Conway's law, which states the following:
-- Melvyn Conway, 1967
This means that the traditional approach of organizing IT teams for large applications based on their technology expertise (for example, UX, business logic, and databases-teams) will lead to a big three-tier application – typically a big monolithic application with a separately deployable unit for the UI, one for processing the business logic, and one for the big database. To successfully deliver an application based on a microservice architecture, the organization needs to be changed into teams that work with one or a group of related microservices. The team must have the skills that are required for those microservices, for example, languages and frameworks for the business logic and database technologies for persisting its data.
- Decomposing a monolithic application into microservices: One of the most difficult and expensive decisions is how to decompose a monolithic application into a set of cooperating microservices. If this is done in the wrong way, you will end up with problems such as the following:
- Slow delivery: Changes in the business requirements will affect too many of the microservices, resulting in extra work.
- Slow performance: To be able to perform a specific business function, a lot of requests have to be passed between various microservices, resulting in long response times.
- Inconsistent data: Since related data is separated into different microservices, inconsistencies can appear over time in data that's managed by different microservices.
A good approach to finding proper boundaries for microservices is to apply Domain-Driven Design and its Bounded Context concept. According to Eric Evans, a Bounded Context is "A description of a boundary (typically a subsystem, or the work of a particular team) within which a particular model is defined and applicable." This means that the microservice defined by a Bounded Context will have a well-defined model of its own data.
- Importance of API design: If a group of microservices expose a common, externally available API, it is important that the API is easy to understand and consumes the following:
- If the same concept is used in multiple APIs, it should have the same description in terms of the naming and data types used.
- It is of great importance that APIs are allowed to evolve in a controlled manner. This typically requires applying a proper versioning schema for the APIs, for example, https://semver.org/, and having the capability of handling multiple major versions of an API over a specific period of time, allowing clients of the API to migrate to new major versions at their own pace.
- Migration paths from on-premise to the cloud: Many companies today run their workload on-premise, but are searching for ways to move parts of their workload to the cloud. Since most cloud providers today offer Kubernetes as a Service, an appealing migration approach can be to first move the workload into Kubernetes on-premise (as microservices or not) and then redeploy it on a Kubernetes as a Service offering provided by a preferred cloud provider.
- Good design principles for microservices, the 12-factor app: The 12-factor app (https://12factor.net) is a set of design principles for building software that can be deployed in the cloud. Most of these design principles are applicable to building microservices independently of where and how they will be deployed, that is, in the cloud or on-premise. Some of these principles will be covered in this book, such as config, processes, and logs, but not all.
That's it for the first chapter! I hope this gave you a good basic idea of microservices and helped you understand the large scale topics that will be covered in this book.