Putting an End to Platform Refresh Cycles Once and For All
Software refresh and upgrade cycles can often become the bane to an organization. They continually have to be justified, paid for, and take a lot of time and energy to pull off. We used two new technologies—microservices and Docker containers—to avoid yet another costly, time-consuming platform refresh cycle. Here’s how you can, too.
We hear it all the time: technology is changing the world faster than ever before. Many people have argued that it is our needs that drive these innovations—necessity is the mother of invention, as they say—but I believe there are two main reasons.
First it is our wants, our aspirations, that push the tech world forward more than anything. This is true for myriad domains, from the watches we wear to the cars we drive, from smart refrigerators to smart cities, from social media to e-commerce.
Second, alongside this acceleration of technological innovation has been a commensurately rapid rise in open-source software. Some of the best software I am using (Moodle for e-learning management, Drupal for content management, Docker containers for virtualization, and Jenkins for build and deployments, among others) are built by the community and are free for anyone to use. A group of innovators in San Francisco or Bangalore develops a more efficient technology that replaces an existing one. Far away, in Tallinn or Tel Aviv, another team of programmers may be working on an even better one that will soon usurp the usurper. The king is dead. Long live the king!
Now let’s talk bout the corporations who are in the business of making money—i.e., creating value for their shareholders. In order to do that, they compete, they lead, they take risks, and, most important, they differentiate their products and services from their competitors and provide the best possible customer service.
The last point is very important. If the product or service is software or offered via software, then software becomes the key for an organization’s success. But given the drivers of technological change I mentioned above, the question becomes, How do these software-driven companies keep up? How do they quickly embrace the newest upgrades, features, or applications in the market while simultaneously continuing to differentiate themselves? Embracing these changes can be daunting and expensive for most companies.
The most common solution you may know (or even use yourself) is the platform upgrade or platform refresh cycle, also known as the technology refresh cycle. The intent here is to not only take advantage of new technology in the market but also some combination of user experience enhancements, new requirements, scaling needs, security aspects, new data-crunching methods, and the like.
The Problematic Platform Refresh Cycle
Let’s take a simple hypothetical e-commerce site as an example. Refer to Figure 1, below, which shows the current version of the site first built in 2013
Now it’s 2018, and this company is growing and needs to offer more functionality in existing components (say, the shopping cart) and at the same time utilize third-party services and create new revenue-generating features like advertisements. The typical way to do this—the technology refresh cycle—would look something like the model depicted in Figure 2.
While this is certainly one approach, there are two major problems:
Heavy investment. Re-architecting and developing new platform is no small undertaking. Usually some part of the existing platform is reused, but then it is mostly about replacing old technologies with new (“same over same”) and taking advantage of new or advanced applications, including open-source components or available DBs in the market. Add in new-skills hires, new processes, staff training and development, and thousands of additional meetings, and no wonder it is so expensive to build and develop a new platform!
Time. It takes a considerable amount of time to build the new platform. Think about it: the new offering must noticeably outperform the existing offering to impress customers. Meanwhile, if the existing platform is not operating as expected and not differentiating enough, companies may lose customers while the refresh cycle implementation is in progress. Time, as always, is of the essence.
The average lifespan of such software platforms has historically been about five years, and that figure is steadily decreasing. So, once companies go through this refresh cycle, usually they go in lights-on mode. Investments subside until the next refresh cycle. Not that new features aren’t added—indeed, organizations proudly say that they are agile and do bi-weekly releases—but these additions are small features, not big technological shifts that can differentiate their products. They are not able to take advantage of new software technologies because they are locked in with the technologies they selected during last refresh cycle. Therefore they must wait until the next refresh cycle for major technological shifts, then build yet another business case for the platform refresh.
I once faced similar issues with my own team. We also encountered other problems:
Longer deployment cycles
We knew it was time for another platform refresh, but we also realized we needed to do it differently this time. Not only that, we wanted to kill this refresh cycle forever. We wanted to be able to take advantage of new technologies and features that hit the market almost immediately, thus differentiating our offerings much sooner than waiting for our next refresh cycle. I also wanted our team to be excited all the time rather than just during refresh periods.
It turns out we were able to address all those issues with two technologies: microservices and containers. How? Figure 3 lays it out:
As you can see, microservices enabled us to do the following:
Select the technologies and open-source applications we wanted to use. We had the flexibility to select what was best in the market, and we retained the flexibility to replace that particular software component anytime we felt there was a better alternative. We didn’t have to wait four to five years—i.e., until the next refresh cycle. For example, six months down the road, if there is better shopping cart solution, it can be replaced without touching or impacting any other microservice.
Scale appropriately. Not all components or functions are required to be scaled at the same level. For example, we just scaled the required components, as in Figure 3: the shopping cart and the ads rather than every service. This reduced our overall infrastructure cost because we didn’t have to scale the whole platform to the same level. Not only that, we were able to scale up or down on demand moving forward.
Increase simplicity and maintainability. This separation of functions provided enormous flexibility, as each microservice could be managed, maintained, scaled, extended, reused, and replaced independently of other microservices.
Exploit more options. Last but not the least: choices. Unlike a monolithic application, where all application components may have to use a single database, platform, and programming language, microservices-based applications offer the opportunity to use the best tool for each specific job. One microservice might use Oracle on Linux OS and another might use a NoSQL database running on Microsoft OS. Long-term commitment to technology stacks is no longer necessary.
I learned a lot from this project and transition, including how to:
Pitch the investment in microservices and containers to my executives from a business perspective
Architect the solution that met the needs I described above
Manage the organizational change and impact due to this transition
Create a culture of DevOps and agility
Compare and select the right tools that enable such a transition
…and My Book
My final takeaway turned out to be the one that probably changed my life more than any other: I decided that I had learned so much that I wanted to share the lessons with others. I decided to write a book!
The result—after nearly two years of late nights and weekends spent writing—was my first book, Microservices and Containers, which will be published by Addison-Wesley later this month. I hope it will encourage more technology and business leaders like myself to utilize these revolutionary technologies themselves. If you’re wondering when your team should consider transitioning to microservices and containers, the answer is probably now. Dive in!
Feel free to comment below or reach out to me directly at firstname.lastname@example.org.