Peace of Mind as a Service
For business folks - after reading this book, it might seem like process automation - implementing continuous delivery and integration is a quick win. It is an exciting journey for some tech folks where they can implement some internal things and processes without being disrupted by the (internal or external) customers. The reality is that internal DevOps is very often a mess, and the half-deployed automation is just making the complex things even more complicated.
This blog post is about an idea we had to build the packaged/boxed/easy-to-buy devops service provided 24/7 with SLA’s to let the CTO’s over the world win :-)
First, let’s figure out why it is so important to solve this issue.
Which fights you’re going to fight?
If you’re in charge of a digital transformation project or even building a startup, there’s always this big question of where we invest our effort. Are the open-source components a real shortcut? Which elements should you buy on the market, and which ones to build on your own?
This is a question of which fights you’re going to fight by knowing which ones you’re able to win. Knowing your limitations, you must pick just a few. The fact is that the complexity and amount of software required for a successful digital transformation are only growing. At the same time, the urgency for the time to market is increasing with increasing competition.
What I’ve heard in my 12+ years in digital commerce from the merchant-side CTOs was usually something like: “We’ve got a budget, it’s not unlimited, so my CEO is asking me for results. I’ve had a hard time dealing with all these maintenance/devops costs around the actual value chain.”
The Almighty ROI
Simply, a business is rarely entirely OK with accepting costs that aren’t easy to justify. I mean, justify as in having to explain spending more customers’ dollars, having two or three devops folks dealing with service level agreements (SLAs) just to keep things going. Simultaneously, having another two or three devs working on new features is like you’re wasting 50% of the budget that one could have spent on wins like new features.
Moreover, with maintenance costs, you can’t win. You just can lose. I mean, if the system fails, despite all the engineering capacity invested into keeping it up, you’re in trouble. On the other hand, no one was promoted by just having the eCommerce site up and available all the time. Better think twice about if you need to host and handle all these netty microservices your team planned to deploy on their own ;)
It’s not about building it. It’s all about maintaining it
When the software was primarily produced in a fixed-budget manner and with waterfall methodologies, there was common wisdom among the software companies. Despite the implementation phase being in red, the knowledge said that the actual money would be made on the maintenance and further development. The initial implementation costs, given the full CTO of a system for its utilization period, typically a minimum of two to three years, were 20-30% of the total cost. The budget spent on features was one-third of the total cost of the project.
That’s probably why API-first, Cloud Native, and Serverless are such hot topics right now. Simply you don’t have to maintain it - or maybe instead - you need way more resources to maintain it. But it’s not the whole story.
The problem with the software you own, created, and deployed is that you need to keep it up and run. If you’ve got a small team, say less than 20 developers, it can be challenging to maintain, deploy, monitor, and keep the 24/7 SLA for a few dozen services. You need to have a devops inside your team.
The developers working on the software you deploy usually won’t be ready. They also won’t like to be on a pager 24/7 and having to have the secure shell (SSH) terminal always on and ready to react for any kind of issue their service will face. You must ensure the correct error and failure handling, network traffic balancing, and redundancy. Then, the team needs to be in charge of the whole thing 24/7
Your application based on enterprise-grade services, meaning maintained and serviced by the provider, is a different situation from having your core business system fully decoupled and supported by your team. I think that cloud computing power is that you don’t have to take care of the details and can fully outsource the devOps to the service provider.
Peace of Mind as a Service
Building a devops shop, providing standardized, boxed devops services for niches like eCommerce could be a great fit. This is a model that worked very well for us when we started commercializing Vue Storefront. We had three different SLA products you might buy - supporting your VSF instance over Azure, AWS, GCP, or any other provider you have.
It wasn’t cheap, but it was worth its price. It’s just an example of product-related support packages. I’m instead writing about the whole-infrastructure services, including DRC (Data Recovery) plans, etc.
I mean the situations you need to react to the DataCenter burns or something like this.
Yes, these situations used to happen.
Compared to the internal costs multiplied by the fear of losing your job if something went wrong - it always works well in enterprise software.
Value-Based Pricing
When your service or product is designed for not letting someone be fired or to burn down the whole business, it means it’s kind of an insurance business model. You can make significant margins having it fixed price (because most of the time there’s simply nothing to do for your team, the team can be small).
This is a huge advantage and a motivation to automate everything, and by doing so, keep it truly safe for the customers (you don’t want to fail it bc. you’re losing money on every hour spent on the problems).
This is a super healthy business model.
Follow the sun model.
Providing 24/7 support might be easier than you think. Having small devops teams hired in countries with a well-known, very high work ethic - spread around the globe. I mean countries like Argentina, Belarus, Vietnam. With three teams, you can simply cover the world. It’s like “Follow the sun” - I like this name; it’s funny, yet very accurate ;)
Quick win? You can find an interesting tutorial on how SWAT team can be organised it and the interview with its team members.
Niches
Starting with some niches, specialization can be fun for devops services. eCommerce is excellent because, in a lot of cases, the SLA expectations are super-high (each hour of lost orders equals hundreds of thousands of dollars of lost revenues for the same issues). At the same time, the current standards they have are often very, very low.
There’s a huge opportunity in providing the specialized devops services for specific tech-stacks/clouds/platforms - making it even easier to buy.
It could be a cash cow.
Is it an idea for a Unicorn? I’m not sure. It will clearly outgrow the eCommerce gains - as the current eShops all have a lot to do to improve their operations. There’s a gap.
The margins can be super high, and the business can be very safe while making eCommerce a better place for CTOs and customers.
If you liked it, if you have or are a part of a devops team - contact us bc. Catch The Tornado is super happy to solve this issue. Once and for all :-)
