It seems that microservices crept out of nowhere and were suddenly everywhere. When it comes to the continuous enterprise and changing business and technology demands, enterprises are being driven harder than ever to be more responsive, agile, and efficient with their technology.
Microservices are in the thick of all of this. Through microservices and service oriented architectures, development teams can be more responsive to the business by more rapidly delivering the application services and enhancements needed to be competitive.
Microservices help large development teams put together a modular development structure, which makes it easier to move swiftly. No one is reinventing the wheel, or a software service, every time common functions are needed. When a new application is needed, developers can grab the microservices that have already been built and start assembling. Also, as enterprises have become more, not less, complex when it comes to development languages and frameworks, microservices help to solve this by making it possible to package these things as independent building blocks.
In our previous two articles, we introduced the concept of the continuous IT enterprise and devops and the continuous IT enterprise stack. The continuous IT enterprise is about continuous collaboration, integration, and deployment. In such a context, we'd be remiss not to take a hard look at microservices.
These microservices, as the name implies, are often (not always) small and singularly task focused. They're decoupled from the underlying infrastructure and applications, but they didn't come out of nowhere. In reality, they are a natural evolution of software oriented architectures and that loosely-coupled the architectural strategy.
But for today's developer and devops practitioners, the history doesn't matter. What does matter is that microservices are a great way to promote discrete, decoupled code that will enable shipping software that delivers business value fast.
In addition to the primary business benefits of microservices, there are many technical benefits, such as a more resilient architecture, they scale and are easy to understand and develop and deploy, and are not locked into applications. Not all is a benefit with microservices. Changes to the API on which they depend can cause breakdowns and complications, and certain types of testing needs to be revised so that is still effective in a microservices architecture. For instance, security tests should be conducted on the microservice itself and also on the larger applications it supports, after everything is integrated together, to ensure new vulnerabilities aren't introduced to the entire application.
Most importantly, microservices enable the focus to be on what matters: the business's needs, the user experience, development, and considerably less time on thinking about architecture, and even less time managing infrastructure. So how do developers best approach microservices?
First, let's look at the types of microservices:
The first type microservices I'd like to discuss are custom microservices. With custom microservices, custom logic services can be developed to grab the data they need to work with, or connect to external systems, conduct common transaction, and perform any other task that is repeated often.
Automatic microservices are data objects that support relations in application dependencies. These can be formulas, metadata, to conduct basic (CRUD) operations in a data repository. What are their benefits. In some cloud platforms, these are automatically exposed in the form of APIs and should also include REST based services for external systems.
Process-driven microservices are hybrids of of automatic and custom microservices for executing logic or workflow processes. [This is all about Processbuilder in the ebook, do we address these when speaking about microservices broadly?]
Data object microservices use or analyze a data type. Enterprise systems commonly aggregate data from many systems -- cloud services, on-premises systems, partner and customer systems -- with data object microservices.
The result is that developers spend time integrating data within the microservice implementation, which impacts maintainability.
It doesn't matter which types of microservices your organization uses, the same best practices come into play. And most of the best practices you will find very familiar with SOA best practices. These are services that grab data and access resources, but don't try to solve every possible use case with data that a full application wouldn't provide. When designing with this mindset, keep the following in mind:[1]
- Microservices do one thing
- Discrete data entities, or business functions are always decoupled
- Avoid middleware whenever possible
- Choose the best language for the microservice
- Need to understand logic and decision trees thoroughly
- Utilize consistent methodology for data access, so microservices and data are loosely coupled
For most organizations, microservices require a big change in architecture perspective as microservices are designed to manage different business functions such as clients, accounts receivables, accounts payable, order status, and so on that can be utilized as services separate from an application. While this approach does provide many benefits, it does require organizations think about strategy and implementation.