Microservices – the most frequently asked questions
What are microservices all about? What changes can developers expect when switching from monolith to microservice? And how does DevOps fit into the mess?
If your boss ever asks you if you want to switch to microservices, don’t bluff. Dr. Mark Little, Red Hat’s Vice President of middleware engineering, explains the basics of IT’s monolith-killing trend.
JAXenter: What exactly are microservices, and why are they needed?
Dr. Mark Little: Microservices are a new software development pattern which has grown out of the recent trends in software development and software management practices, in order to increase the speed and efficiency of developing and managing software solutions.
Agile methods, DevOps culture, PaaS, application containers and the widespread adoption (both mentally and technically) of CI/CD methods across the marketplace are making it possible to consider building truly modular large-scale service systems for both internal and commercial use.
DevOps is an approach to culture, process, and tools, for delivering increased business value and responsiveness through rapid, iterative, and high-quality IT service delivery. It can be implemented for a monolithic application very successfully.
What challenges and risks do organisations often face when switching from a monolithic system to microservices. And what role do microservices play in the DevOps approach?
First we have to understand why people may want to switch. Not all monoliths are bad, and even those that are not working for you may not benefit much, or immediately, from moving to microservices. Other approaches, such as deploying more effective software engineering and architecture may help. Microservices are not a silver bullet for all problems, and require significant investment to be successful.
Service discovery: Multiple services might be collaborating to provide an application’s functionality. It could be tricky in a cloud environment where the services are ephemeral and possibly scale up and down. Resolving the services that are required for a service’s operation is a common functionality. Services need to register with a central registry and other services need to query this registry for resolving any dependencies.
Service replication: Each service needs to replicate, typically using X-axis cloning or Y-axis partitioning. There should be a standard mechanism by which services can easily scale, based upon metadata. A PaaS, such as OpenShift, can simplify this functionality.
Service monitoring: One of the most important aspects of a distributed system is service monitoring and logging. This allows you to take proactive action, for example, if a service is consuming unexpected resources.
Resiliency: Failure in software occurs, no matter how much and how hard you test it. The key question is not “how to avoid failure” but “how to deal with it”. This is all the more prominent in microservices where services are distributed all over the Internet. It’s important for services to automatically take corrective action and ensure the user experience is not impacted.
DevOps: Continuous Integration and Continuous Deployment (CI/CD) are very important in order for microservices-based applications to succeed. This is required such that errors are identified at an early stage and little to no coordination is required between different teams building different microservices.
What are some of the requirements and best practices for a good microservices architecture?
People and groups looking to embrace microservices should consider the following aspects when developing them:
Independently scale: Each microservice should scale independently using X-axis (cloning with more CPU or memory) and Z-axis (sharding) based upon their need. This is very different from monolithic applications that may have very different requirements and yet must be deployed together.
Independently upgrade: Each service should be deployed independent of other services. Any changes local to the service can be easily made by the developer without requiring coordination with other teams. For example, performance of a service can be improved by changing the underlying implementation. As a result this maintains the agility of the microservice. This is also a great enabler of CI/CD.
Easy maintenance: Code in a microservice is restricted to one function of the business and is thus easier to understand. IDEs can load the small code very easily and keep the developers productive.
Potentially heterogeneous and polyglot: Developers are free to pick a language and stack that is best suited for their service. Even though the organizations may restrict the choice of technology, you are not penalized because of past decisions. This also enables the rewriting of the service using more suitable languages and technologies. This gives freedom of choice to pick desired technologies, tools, and frameworks.
Fault and resource isolation: A misbehaving service, such as with a memory leak or unclosed database connections, will only affect that service as opposed to the entire monolithic application. This improves fault isolation and does not brings the entire application down, just a piece of it.
Difficult communication across teams: A microservice is typically built by a full-stack team. Thus all members related to a domain are working together in a single team. This significantly improves communication between team members as they share the same end goal.
Does the broader responsibilities of a DevOps approach mean more work for developers, who constantly have to think about the bigger picture?
DevOps gives more responsibility but it also gives more authority to the developer as well. A developer can release a feature on their own schedule but then be responsible for fixing any production failures with it as well. The end goal is always to benefit the business and DevOps practices are known to help with the velocity and agility of an organization.