Abstract
In cloud native architectures, large applications are created from loosely coupled microservices instead of being one monolithic entity. Microservices are small, autonomous, self-contained software components, organized around business domains, which means each part can be easily monitored, tested and updated without affecting the others, bringing greater business and operational speed and agility.
As microservices are integral to cloud-native architecture, it’s tempting to dismiss them as things that happen more or less ‘naturally’ in that environment. This is a dangerous assumption. All types of architectures have cons as well as pros, and organisations need a basic set of competencies in place before considering putting them into production.
Further, deploying microservices in a piecemeal fashion, rather than strategically, is an approach that will inevitably cost an organization dear in terms of time, money, agility and resources in the probably only slightly longer run.
Common errors include deploying technology for its own sake rather than to achieve a specific outcome. Becoming too tool-centric is another pitfall for the unwary – tools are the means, not the end. Those who create an exclusive infrastructure for each microservice will discover that approach rapidly becomes very costly while keep re-inventing the wheel for use cases that cut across capabilities is a pointless, resource-hungry process.
With a proper strategy in place, including good governance, enterprises can ensure microservices are a key enabler for their hybrid integration platform. They will be able to leverage the benefits of microservices architecture instead of potentially replacing an outdated monolithic applications environment with a newer but more expensive, less effective one.
Introduction – the multiple appeals of microservices
In cloud native architectures, applications are broken down into a collection of loosely coupled services encapsulated in software for some good reasons. Correctly deployed, microservices can bring some big business and operational benefits. This introduction is not exhaustive.
Each microservice can be updated and swapped in and out without impacting the others that together make up the application.
Microservices leverage DevOps methodologies and are easier to maintain and test because these processes don’t involve the entire application.
Microservices are organized around business capabilities and are usually owned by a small, expert team.
The attributes described above mean cloud native architectures can create, deliver and maintain large and complex applications far faster than their traditional equivalents.
Organizations can evolve their technology stack by following key principles, rather than be limited to a particular technical framework to build and use microservices.
Each microservice is exposed using a standard protocol for easy consumption and sticks to service orientation principles for publishing and discovery.
Microservices-based architecture is the evolution of service-oriented architecture (SOA) and has key attributes that SOA lacks:
- SOA is reliant on the messaging protocols of enterprise service bus (ESB) for communication between an applications’ components in a centralized manner with protocols such as SOAP while microservices communicate using lightweight protocols such as REST APIs or binary protocols such as Protocol Buffers or Apache Thrift.
- each microservice can be deployed and scaled independently of the others that make up the application.
There are a number of readily available, JavaScript code-centric, microservices frameworks, like Spring Boot or Node.js or Eclipse Vert.x, for developers to use out of the box.
Section 1
What could possibly go wrong?
Microservices have a lot more moving parts than traditional applications, and require new ways of working and new skill sets. Without a coordinated, strategic approach to building, deploying, running and maintaining microservices, organisations will not reap their full potential. In this section we have a brief look at some of the most common mistakes concerning microservices.
Technology is only part of the story
Moving to a microservices architecture is a fundamental shift in organizational mindset, team structure and organizational culture because these services rely on the DevOps methodology and deployment model.
As ever, cultural change and resistance to new ways of working present far more serious barriers to success than the technology per se.
Don’t get distracted by the tools
It’s easy to get caught up with mastering and using new tools and lose sight of the end goal. Tools are important but they are the means to an end, not the end in themselves. Despite persistent, collective wishful thinking in IT departments, there is no magic product, resource or tool that holds the key to universal success.
Remember, outside science projects, technology for its own sake never results in return on investment.
What are you trying to do?
Do not assume that microservices are always the best option in every situation. Start with the desired business outcomes and figure out the best way to deliver them rather than starting with figuring out possible uses for a new technology.
To read more
