Prior to Microservices "being a thing" that spawned countless articles (ok, 1.87m for https://www.google.co.uk/#q=microservices) it was a pretty well understood design pattern.
Harking back to the late 90s a well known sell-side system (hint, think of where the McLaren cars are based) used to be (still is, but cloud deployed) based upon a microservice orientated model where each application module consisted of a number of services based upon a number of patterns:
- request/reply
- publish/subscribe
- transaction handling
- journaling
- database lazy writing
- database reading
- monitoring (think of a predecessor to ITRS and the various DevOps platforms)
The main code was written in C/C++, with an in-house scripting language and a proprietary in-memory transactional database (how transactional while in-memory - file system journal to ensure persistence and recovery). All wrapped up on the server side with TCL (which was and still is a reasonable choice for glue to combine larger code modules).
Let's compare that to a good description of Microservices by Martin Fowler from 25th March 2014 which states:
In short, the microservice architectural style [1] is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies...
Monolithic applications can be successful, but increasingly people are feeling frustrations with them - especially as more applications are being deployed to the cloud . Change cycles are tied together - a change made to a small part of the application, requires the entire monolith to be rebuilt and deployed. Over time it's often hard to keep a good modular structure, making it harder to keep changes that ought to only affect one module within that module. Scaling requires scaling of the entire application rather than parts of it that require greater resource.
These frustrations have led to the microservice architectural style: building applications as suites of services. As well as the fact that services are independently deployable and scalable, each service also provides a firm module boundary, even allowing for different services to be written in different programming languages. They can also be managed by different teams .
We do not claim that the microservice style is novel or innovative, its roots go back at least to the design principles of Unix. But we do think that not enough people consider a microservice architecture and that many software developments would be better off if they used it.
Somehow for many firms this microservices architecture is "new", yet for this specific case it's about 20 years old and has roots in some of the UNIX patterns - everything is a file, do one thing and do it well and so on...
Comments
Post a Comment