We work with enterprise customers and although each company feels it’s a unique and delicate snowflake, most of them think, purchase, and implement the same things from an enterprise software point of view.
This typically means that every organization has a monolith — a software project that has grown to be mission critical and gained complexity and size with ever-growing challenges to maintain it or to have it running quickly, securely, and modernly.
The way that the software world (first in startups but now also within enterprise software ) has innovated after years of building bigger and thus slower legacy systems was first to adopt the SOA (Service Oriented Architecture) approach breaking up their monolith into several services that communicate between themselves through the network.
This was a good step in the right direction and led to the birth of web services and of the distributed computing approach but typically the projects were still part of the same codebase and run by the same people.
In the past years, these services were broken down, even more, to deal with and deploy a microservices architecture, basically thinking about your application as something built of dozens of stateless microservices typically communicating through a shared service bus or message queue.
This has a profound effect on the scale, development speed, and way that developers take responsibility in an enterprise organization. By breaking the software into many small microservices we’re achieving a few things
Working in a test-driven approach also helps you find problems before you deploy them because you would be defining the health of the service and would test to make sure it is running correctly as a separate unit and in the larger “end to end” context.
One of the main things we do in Linnovate is handhold organizations in their path to break up the monoliths and to host and manage them with modern deployment toolings such as docker, docker-compose, and Kubernetes (we’ll try to dive into that in the upcoming blog posts).