Escaping the Monolithic Trap
Usually, the way we put together an application results to sets of UI/UX that should appear to work together as one. Naturally, we create the application as a single project, which we then build and deploy as a single product. All is well and good. That is until microservices become the norm.
In order to promote microservices, it defines and subtly demonizes monolithic applications. The truth is, there's nothing wrong about creating monolithic products. It's natural. You want a bike, you get a whole bike. You want a car, you get a whole car. You want an airplane, you get a whole airplane. It's not like you can get wheels here, wings there and some other parts to sit everywhere else, and still say you have a plane! Although technically you can have a plane, it does not mean it can already fly. You need to put them together first into one monolithic machine in order for it to actually function and work as a plane.
In a very mechanical world, that makes a lot of sense. However, the software world is a whole new world in its own right. More so, software can be more than just how we understand the world to work. Software does not have the limitations of physical mechanics. Like for example, it does not have to be one single whole product installed in the same machine in order to work. Software can be split apart and distributed across geographical plains, and still work as if it is one whole product.
The very essence of microservices is exactly that. You can follow specific guidelines and patterns in such a way that the application you develop can be distributed into its parts, and each part can be given a life of its own. A typical example would be to think of an application as something that can be made up of seven parts:
It doesn't mean that applications should immediately be created into microservicing its typical parts. That can be done as an afterthought, really -- like starting monolithic, and then breaking it apart. However, there is also no harm in starting a new application as readily microserviced from day one. But, would it be worth the extra mile?
Beyond microservicing concerns, the value of actually doing so can be assessed by considering the application's immediate or eventual needs to work with existing or anticipated administration/hosting strategies, privacy/security strategies, back-end processing strategies, operational strategies and business intelligence strategies. Discussing these go way beyond the scope of this article, but understanding them can help in the high level planning and decision making processes during development.
For some businesses, microservices can be an overkill when a monolithic approach is actually good enough. Still, in an "everything is in the cloud" future, creating applications as microservices from the start can make for a cheaper and quicker transition when the need arises. Consider for example an application's membership and authentication/authorization features. If the business expands with partnerships that would integrate products/services via shared members, having these parts as microservices can save the company from the sudden growth and the new onslaught of transactions. Each microservice can be administered separately without necessarily affecting the other parts, if not keeping the effects at a minimum or at manageable level. As a result, there can be no unnecessary down times. Also, it offers the potential for the company to be in business with its new partners faster and sooner.
Software can be monolithic. However, it is important to know that it does not have to be... all the time. Be ready. Be flexible. Be smart.
In order to promote microservices, it defines and subtly demonizes monolithic applications. The truth is, there's nothing wrong about creating monolithic products. It's natural. You want a bike, you get a whole bike. You want a car, you get a whole car. You want an airplane, you get a whole airplane. It's not like you can get wheels here, wings there and some other parts to sit everywhere else, and still say you have a plane! Although technically you can have a plane, it does not mean it can already fly. You need to put them together first into one monolithic machine in order for it to actually function and work as a plane.
In a very mechanical world, that makes a lot of sense. However, the software world is a whole new world in its own right. More so, software can be more than just how we understand the world to work. Software does not have the limitations of physical mechanics. Like for example, it does not have to be one single whole product installed in the same machine in order to work. Software can be split apart and distributed across geographical plains, and still work as if it is one whole product.
The very essence of microservices is exactly that. You can follow specific guidelines and patterns in such a way that the application you develop can be distributed into its parts, and each part can be given a life of its own. A typical example would be to think of an application as something that can be made up of seven parts:
- membership (sign-up),
- authentication/authorization (sign-in/sign-out),
- catalog,
- transaction modules (orders/shopping cart),
- payment gateway/modules,
- reports, and
- value-added modules/content (help/support content/tools, marketing info/materials, etc.).
It doesn't mean that applications should immediately be created into microservicing its typical parts. That can be done as an afterthought, really -- like starting monolithic, and then breaking it apart. However, there is also no harm in starting a new application as readily microserviced from day one. But, would it be worth the extra mile?
Beyond microservicing concerns, the value of actually doing so can be assessed by considering the application's immediate or eventual needs to work with existing or anticipated administration/hosting strategies, privacy/security strategies, back-end processing strategies, operational strategies and business intelligence strategies. Discussing these go way beyond the scope of this article, but understanding them can help in the high level planning and decision making processes during development.
For some businesses, microservices can be an overkill when a monolithic approach is actually good enough. Still, in an "everything is in the cloud" future, creating applications as microservices from the start can make for a cheaper and quicker transition when the need arises. Consider for example an application's membership and authentication/authorization features. If the business expands with partnerships that would integrate products/services via shared members, having these parts as microservices can save the company from the sudden growth and the new onslaught of transactions. Each microservice can be administered separately without necessarily affecting the other parts, if not keeping the effects at a minimum or at manageable level. As a result, there can be no unnecessary down times. Also, it offers the potential for the company to be in business with its new partners faster and sooner.
Software can be monolithic. However, it is important to know that it does not have to be... all the time. Be ready. Be flexible. Be smart.
Comments
Post a Comment