I was fortunate enough to have had an opportunity to attend a recent meetup held @Thought works, Pune that had an interactive talk with fellow thought workers and Martin fowler.
This talk was part of a series of talks held as part of the first edition of Geek Lounge. Martin Fowler, needs no introduction, he is the father of agile software development; this time around the focus was Micro services
Micro services, is been buzzing a lot in the technology industry for quite some time now, almost all the organization are adopting it and also practicing it. This meetup focused more on the choices one should make before adopting micro-services path of development. Martin made some really strong point to start with where he favored monolith style of development when you are unware of the domain language and it’s a new requirement that cannot be sliced horizontally; as for micro services it is required that you have a clear idea of the boundaries of your services.
Adopting micro services will cost you in terms of processes, resources and infrastructure as it means developing multiple services independently by independent teams which will require continuous integration and delivery model to be full proof. Another, important area Martin focused on was troubleshooting, upgrades, deployment and distributed SLA’s related challenges which become extremely easy to overcome with micro services style of development.
Further, the panel discussed some of the success stories of using micro-services in their project and few challenges that they had to deal with. Most of these challenges were around defining the boundaries of micro-services and using common data that can be shared across. Some of the solutions laid by martin were to adopt mix of monolith and micro-services; by slicing your requirement horizontally so that a single responsibility principle applies to all the services. Later in the project cycle when the requirement is clearer you can divide the monolith into multiple micro-services.
One of the interesting questions one of the panel members asked was about the GUI development, whether it’s possible to adopt this style; the answer was yes and no both as it becomes quite challenging when a GUI is shared by multiple micro services which will then cause dependency and will defeat the purpose of single responsibility principle. There were few who tried to do it but were unable to clearly setup a process around it.
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.
One reasonable argument that Martin put forward was that you shouldn’t start with micro services architecture. Instead begin with a monolith, keep it modular, and split it into micro services once the monolith becomes a problem. (Although this advice isn’t ideal, since a good in-process interface is usually not a good service interface.)