We live in the world of now, where everybody expects fast customer service. Who wants to wait for a search result on a web shop? Who wants to wait for a reply on a customer support ticket? In order to stay relevant, companies who build marketplaces or make their offerings in a digital world, have to build the right foundation to stay top of the game. After Data Talks #20 with Thomas Kasemir, I am happy that he spend one more session with me to discuss why you need the right tech architecture to be successful tomorrow.
If you are looking for a write up, please continue reading:
What tech is needed to scale and why is the move from old tech to new tech not soo easy?
Both, the mature monolithic architecture and the modern microservice architectures have their pros and cons. Both address certain challenges very well but have setbacks in other areas. None of them is removing complexity, a complex problem always needs a well design and thought through solution.
A monolithic architecture is simple to develop and change, straightforward to test and deploy and easy to scale over multiple instances. Good tooling is available with powerful IDEs, new team members can start fast and add code. But with the ongoing life-cycle of the application, with more development and features, refactorings, platform updates, new libraries in the technology stack and more distributed developers to keep in sync and build, test and deploy take longer and longer, the benefits are becoming setbacks. At the same time, the code base becomes too complex for every developer to understand, problems harder to fix, changes are creating side-effects and new problems as the impact is hard to manage. Scalability also becomes harder as different code modules have conflicting resource requirements and require compromises on the server configuration. Everything becomes more and more complicated, slower and less scalable over time – welcome to monolithic hell.
A microservice architecture is addressing most of those challenges, especially for large and complex applications, but it also has drawbacks and is not a silver bullet. Services are loosely coupled mini applications and communicate only via APIs. One approach to ensure loosely coupled services is that each service has its own datastore. As you can’t bypass the API, it is much easier to keep the modularity of the application during the life cycle. Services can be developed, tested, deployed and scaled independently. This reduces complexity, increases fault isolation and enables larger development organizations with many small and autonomous teams.
There is also a number of significant drawbacks and issues, which need to be addressed, like finding/cutting the right set of services, managing a distributed system with complex dependencies, deploying features and implementing transactions that span multiple services. A very high level of automation on all levels like build, test, package, deploy and monitoring is mission critical.
For moving from monolithic hell to a microservice architecture, there are basically two alternatives, with many mixed variants in-between. You can restart from scratch oder move the old monolithic product piece by piece to the new architecture, technology stack and paradigm. Both approaches are coming with pros and cons on time to market, features and migration path.
For the engineering team, the move is a huge paradigm shift. Shipping software in boxes with a manual has nothing to do with operating your solution for the customer. You have to design every feature for (cost) efficient, secure and maintenance-free operation. The developers have to understand that his is now their responsibility. Sometimes, they need to feel the pain and then come up with brilliant solutions. You also have to establish a full product operation team, building new skills and processes, being end-to-end responsible for your service, 24×7 and for every customer and his data in every time zone. The engineering team is now in the front-line of customer success, renewals and revenue.
Beyond engineering, this is also a huge shift for the whole company on how you bring your solution to the market, how to sell (with free trials online in self-service), how to do marketing, act on public feedback, track reputation and ensure high customer satisfaction all the time for best renewal rates.
Bottom line, this is not about moving from old to new tech, but a full paradigm shift for the product team and the whole company. This requires to changes almost everything and reinvent the company.
Data Talks 