Operations | Monitoring | ITSM | DevOps | Cloud

As I said before, Speed is King. Business requirements for applications and architecture change all the time, driven by changes in customer needs, competition, and innovation and this only seems to be accelerating. Application developers must not be the blocker to business. We need business changes at the speed of life, not at the speed of software development.

Microservices are an accelerating trend thanks to rousing endorsements from the likes of Google, Netflix, and Amazon. The microservice architecture is advantageous for it’s scalability, agility and flexibility. In contrast, the monolithic approach is the traditional tried-and-true model for building software. It’s much easier to debug and test. But how do you know which approach is best for your organization?

For years, enterprises have been employing monolithic applications with complex functional frameworks. But today, with advanced solutions built ith API’s and Microservice architecture are putting an end to their realm. With ever-changing requirements in the IT world, enterprises are required to adopt advanced applications with sophisticated features and functions that can accommodate changes throughout.

Although the fundamental concepts of site reliability engineering are the same in any environment, SREs must adapt practices to different technologies, like microservices.

I recently had the opportunity to read the book “No Rules Rules: Netflix and the Culture of Reinvention” by Reed Hastings and Erin Meyer of Netflix, and it dawned on me that while this book wasn’t at all focused on Netflix’s technology, the global company-wide culture had a significant impact on its technology choices. The book focuses on the many times Netflix had to reinvent itself and transform its business in order to revolutionize the entertainment industry.

It’s a common story: the product team gets early success and grows into a large monolithic code base. While everything is in a single code base, features can be added quickly. This is partly due to the ability to leverage shared code across each feature in the codebase. When your team is adding a new feature, a developer can leverage the existing codebase for needs such as logging or special error handling.