Microservices is a software implementation pattern and does not, by itself, represent any new capability or feature to the user of the system. Simply put – a consumer of an application, will not know nor care whether the application is microservices-based or not.
For the provider and maintainer of the application, however, a microservices architecture represents not only a big shift in the way things are done, but also an opportunity for much greater agility, velocity and cost-reduction.
At a high level, a microservice is a software component which is:
The conversation around microservices seems like a pure technical one, but it does have some profound business impacts, such as:
The first and foremost reason for choosing a microservices architecture is the speed of developing new features and offerings. Having every single business process as its own product - managed by an independent group of people and independently deployed – means that the time to develop it is dramatically reduced. Eliminating dependencies on other software components eliminates bottlenecks and waiting periods which can be the difference between a product reaching the market on-time or too late.
In a continuously changing market, there’s a need for continuously iterating on features and offerings. Reducing the speed of change, reduces the backlog of unfinished work and provides a much better adaptation to changing market needs.
In addition to the reduction in time, a microservice architecture also results in a reduction of risk. Having separate microservices means that you are not faced with a house-of-cards scenario where every change can yield unpredictable results.
Last, but not least, reduction in time and risk also results in reduction in cost. For example, there are fewer resources needed to make changes and since there is less chance that a complex fragile monolithic structure will break down, there are less costs associated with break-fixes.
By offering a functionally-decoupled approach, where an overall application is broken into small components, it’s easy to see why it’s easier to write and maintain the application. Instead of having to consider the entirety of the code-base and multiple dependencies teams can focus on the one small component they are dealing with, confideant that it is truly independent from all others.
By breaking down the application into small, independent, runnable components - scalability becomes just a matter of bringing up additional instances of the required microservices. This can even be automated to help offset cost vs. performance.
Managing an application built in the microservices pattern requires a great deal of automation. This is very much in line with the idea of DevOps which continues the theme of reduced time and risk by providing powerful automation tools and concepts to the testing and deployment stages as well as to the writing of the code.
While not mandating it, the microservices pattern lends itself very well to agile development patterns. Moving from waterfalls to sprints makes a lot of sense when the applications boundaries are well defined.
While the power of microservices is very well understood and indeed used in more recent applications, most enterprises today have a great deal of existing monolithic applications and systems. Migrating these applications into a newer architecture is a costly, risky and lengthy project, especially when considering the fact that these applications tend to be the core systems at the heart of these enterprises. This means that in a lot of enterprises, innovation happens only in the periphery and not at the core of the business.
OpenLegacy provides an automated and standard way of functionally-decoupling a monolithic core application by creating a microservices architecture on top of it, consuming it as a data-store but leaving it unchanged.
An automatically generated OpenLegacy microservice is a self-contained standard Java component which has a standard interface – an API, a business logic which deals with a small problem domain and as a data storage it has an SDK which refers back to a business process or data on the legacy core applications. This maintains the concept of an independent component as much as possible. While changes on the backend applications might affect the microservice, as long as the legacy core system remains unchanged – the microservice is completely independent and can be changed without any consideration to any other component.
This approach is quite different than a typical “Integration microservice” offered by other integration vendors, which is a microservice dealing only with an integration process and is dependent on other microservices. Such dependencies essentially contradict the benefits of the microservice architecture and eventually leads to a kind of a decentralized monolith which might span multiple separate components but remains as complex and hard to maintain as any monolith application.
OpenLegacy brings innovation to the core of the business.
With OpenLegacy a large and complex enterprise can make the leap to the latest technologies and architectures without the prohibitive risk, cost and time investments this kind of project usually takes.
Once completed, an enterprise can now enjoy a business velocity and agility usually reserved for smaller players and drive innovation from the inside out.