Let’s admit: We are technology enthusiasts or at least we want to brand ourselves that way. We want to apply the latest technologies to solve business problems. Often however, what is required is examining the finer nuances of requirements of which Technology is only one part. A holistic view of requirements and business extends much beyond what any suite of latest, “state-of-the-art” technologies can offer.
It is true that a greenfield project or application is every technologist’s delight. Not having to deal with existing code or design is like giving a fresh canvas to the painter.
In the real world however, new applications have to interact with older ones in varying degrees. Whatever the latest buzzword may be in fashion: “Digital Transformation”, “Microservices”, “state-of-the-art responsive design application” et al, it is a tool to achieve a purpose and not an end in itself.
Take the case of Microservices for example. Say, an e-Commerce company realizes that having twice a year deployment for the entire application is just too cumbersome and causes a lot of “hot fixes” to be rolled out later on. The CTO decides that she can’t allow this to continue. She determines that there should be less inter dependencies among modules, so that all these modules can follow their own development and deployment cycles autonomously . The CTO has further learned that one way to achieve this purpose is Microservices powered with CI/CD. We are tasked with coming up with a strategy to implement Microservices in the organization. We start immediately and after doing some research, contact a company “ServicesRUs” that claims that they specialize in Microservices. A sales representative from “ServicesRUs” tries to impress us by offering latest suite of technologies: SpringBoot, Kubernetes, Docker, Mesos, etc.
There are 2 completely different paths that we can take from here:
1) Give in to the sales pitch, and let “ServicesRUs” deal with it entirely. After all, if they know so much technology, then they must also be able to figure out rest of the things themselves. Or,
2) Ask specific questions to “ServicesRUS”. Like how, in a Microservices model for our e-Commerce application, will we maintain the inventory across different modules like Catalog, ShoppingCart, and Order Processing? What if inventory is a legacy Data Store maintained in a Mainframe DB? How will we distribute it among the 3 Web Services? If a customer is looking at an “iPad” in the catalog that shows 100 of them available, then wouldn’t we want the number of items to be updated in case another customer buys that same type of iPad? Even after employing Docker container and Kubernetes and making our services individually deployable, if all the modules still have to refer to the same Data Store and backend services, then are they truly decoupled?
As is obvious, much better return is obtained with the 2nd approach, since it requires more involvement and research. A lot of times however, things go the 1st way, and we are blissfully ignorant of the disaster that awaits us on the day of Production rollout.
How we solve this problem is beside the point since the purpose of the article is to underline the need of taking an extensive view of solving a business problem and understanding that technology is only a means to solve the same. Still, I will go ahead to complete the story for the curious. In this case, the answer depends on the Domain model. An EventDriven framework can be implemented behind the scenes in such a way that each Microservice can have its own local DB . Every time a transaction takes place, an event pushes the updated item inventory information into DBs of other Services and also into the Mainframe DB. This could be a simplistic way to explain, but still drives the concept home that Microservices is not merely about getting ApacheCamel, and other technology suites and tools. It is about understanding the Domain Model and applying Microservices on top of that within the context and transaction boundaries defined for that Domain Data.
Extending upon our Microservices example, there is more dependency between new and existing applications than we care to acknowledge sometimes.
In my experience, the difference between successful and unsuccessful projects is that in the former, the designers and strategists are able to realize that their new baby is not going to be an Emperor, but rather a Leader with support from Senate, Congress, Courts and other existing institutions.
Recent Comments