devopsy.kinsta.cloud

Author: Carol Carpenter

  • What’s the cost of build versus buy DevOps?

    What’s the cost of build versus buy DevOps?

    Nearly every business today relies on faster, innovative technology to succeed in the marketplace. How about the coffee you drink, or the movie you’re watching, or the phone on which you’re watching it? Name every business or walk of life. You can argue that technology serves to make it better. If DevOps helps deliver the best services and experiences to you, then should companies making the coffee, movies, and phones also make their own DevOps solutions?

    I completely empathize with the challenges the developers and DevOps teams face in transforming a team or company from traditional development and delivery to an agile lifecycle. I experienced this firsthand at Trend. I led a business unit that acquired a SaaS company for online backup and storage; this young company updated and deployed code several times a day. To integrate their processes into ours was painful. I wish ElasticBox had been an option then. I cringe when I consider the time and costs of lost productivity, wasted development time, and delays in getting to market.

    Faster deployment nirvana

    Every day, I speak to several technology companies. Speed is at the top of their mind. They all experience the pain of not deploying and delivering applications to the cloud fast enough. Most have some number of cloud applications, some customer-facing and many internal on both private and public clouds. To give you an idea of how widespread this pain is, see the 2014 451 Research report. The 451 Research team reported that more than 60% of businesses wanted to deploy more frequently.

    But moving from agile development to agile delivery across an application lifecycle comes at a cost. Companies calculate the cost implicitly and explicitly. I’ve heard feedback from prospects who say explicitly: “I love your product, but I can build the same thing with my developers in xx country.” They usually have many smart development resources and tend to be born-in-the-cloud companies. Others tell me, “This is not our core competency. We don’t want to maintain a cloud application manager. We want yours.”

    Build versus buy DevOps

    At what cost do companies decide to build versus buy a cloud application manager from ElasticBox or one of our competitors?

    • First, you have to answer this question: What is your company’s core competency? Do you really want to divert resources to build your own cloud application manager versus invest in your core offering?
    • Second question: What is the urgency and need? If you have time on your side, taking a year to build your own solution may make sense. If you need a solution tomorrow, then what is the cost, in terms of market impact, competitiveness, customer satisfaction, of delaying a year.

    Once you answer that, you calculate the total cost of owning (TCO) the complete lifecycle of build versus buy. These values must encompass all the phases of building and ownership: acquisition, operation, change management, training, ongoing maintenance and internal support. Time and time again, enterprises only look at the initial build or acquisition cost and fail to fully calculate the ongoing implicit costs.

    Recently, I met with a VP of Engineering who had built a barebones deployment solution a few years ago. Now she bemoans the fact that the costs of maintaining a less-than-perfect solution is too much. Her TCO calculation included the developers, ongoing maintenance, workflow delays, meetings, support tickets, delayed product launches. Her decision to now buy is a no-brainer.

    I’m not arguing that it’s always better to buy than build. But consider the factors—core competency, time-to-market delays, and TCO. We want enterprises to keep building great software that complements their core value proposition. When it comes to agile delivery, consider an experienced partner who handles the same problem for dozens of enterprises. Simplicity, flexibility and speed—those are the barometers of agile delivery success. So developers feel productive, applications deploy faster, and your customers relish the delicious cup of coffee as they watch Netflix on their iPhone.

  • Tuning in to the real pain of customers

    Tuning in to the real pain of customers

    In my product management and marketing experience, I discovered that I carry a deep bias about our product capabilities and why it’s special — before a launch. On a whiteboard, in a spec, or in a usability lab, our product can and will change the world. Post-launch, when customers get their hands on our product, magical things happen. Intended use cases become irrelevant. Intended benefits change. Intended value changes.

    Over the past weeks, I’ve had the privilege of talking to many of our customers and prospects. They educated and helped me reframe the value we deliver to our customers.

    Real pain

    Much has been written about the DevOps revolution, driven by applications moving to the cloud, mobile computing, and the business need to compete. The journey to an agile build-test-release cycle is real, and it’s hard. It’s hard for customers who are cloud-born, and it’s even harder for traditional operations and development teams. Listening to our enterprise customers who are several years into their transformation, I heard a lot about the explosion of technologies and the cultural challenge. The pain of the change is more excruciating than I realized. One large customer told me that two years ago, he (VP of Cloud Operations) and his team couldn’t stand to be in the same room as the development team. Today, they’re collaborating to the point where they now sit together.

    Demanding developers

    Secondly, developers are more demanding. Again, it seems obvious, but hearing firsthand how hard it is to empower developers brings it home. Developers want and require more agile build, release and deployment capabilities, but they don’t want to be infrastructure experts. Enterprises are beginning to offer self-service to their private and public clouds so that developers can have autonomous access to environments and resources. A leading biotech customer told me that he can’t dictate policies and processes anymore, that he needs the researchers and scientists to adopt and embrace what the DevOps team is providing. Finding the appropriate balance between freedom and speed along with control is a common challenge across the board for our customers.

    Delivering value

    At ElasticBox, we talk a lot about the technology and cultural shift in enterprise DevOps teams, and how we can enable greater collaboration by being at the nexus of the transformation. That is what we ultimately deliver to our customers: a new way to deliver applications to the cloud that’s better, faster and more efficient.

    It’s a big promise, and we’re excited to fulfill it. Today, we deliver the foundational tools for self-service provisioning, service catalogs and continuous integration and delivery — wrapped with a flexible box architecture that’s reusable and agnostic to the underlying infrastructure and deployment tools. We approach the problem from a developer mindset to drive speed and autonomy, and at the same time, provide the policies and reporting to ensure scale. We’re hungry to continue learning from you, so check us out and let us know how we can help.