devopsy.kinsta.cloud

Tag: openstack

  • The Last One That Transformed the Future

    The Last One That Transformed the Future

    The headline made her yelp for joy. A year into the future of D-Chip, on a crisp August morning, Phoebe opened the newspaper and swiped to the technology section on her iPad. What she saw was riveting: D-Chip reborn as a star in wearable computing.

    She immediately thought of the article Marc Andreessen wrote on how software transformed the enterprise. It’s true of our company’s story, she mused. The credit for making the headline a reality was due to the stressful events of the last months. Who said stress couldn’t be a game changer? As she picked absently on a plate of fruit and relished the article for the second time, she recalled the events of the past year.

    Flashback a year ago at D-Chip

    Remember how Rachel pitched her enthusiastic idea to Chandler? She wanted to engage six engineers in six months to build an in-house solution. A solution that would integrate D-Chip and Enogo’s systems by letting them deploy in both OpenStack and AWS and manage wearable chip code from a single deployment platform.

    Chandler agreed in theory with the need for a single management platform but didn’t see the sense of doing it in-house. Why side-track from your business goals and spend months building a solution yourself when there are specialists solving this exact problem for many companies facing the same issues? After much debate, they came to a consensus. They decided to evaluate solutions from the best-of-breed products out there and transform their software development lifecycle to reflect the best agile practices. Thus was born the iTransform project.

    The iTransform project

    The name itself was a reminder that transforming was as much a matter of people internalizing and accepting a new way of doing things as much as it was about aligning and unifying D-Chip and Enogo systems. The first order of priority was to understand the pain-points that assailed the company. After a lot of meetings and detailed analysis, they identified key use cases from internal stakeholders, namely the engineering and IT operation teams:

    • Engineering personas, developers, QA, architects, all said the same things. They didn’t have access to the latest tech because it took weeks or months for approval processes to travel up the chain. Then they waited on builds and environments from IT operation teams. Most of the time, the environments in the private datacenter OpenStack cloud didn’t work properly, and deployments never succeeded the first time. It’s no wonder they took weeks or months to release anything decent.
       
      Self-service and continuous delivery were, therefore, the most important criteria for developers, QA, and architects. Without waiting for IT admins or operations teams, they wanted to spin up build environments in test, staging, even production on their choice of pre-configured infrastructure. They wanted to consume in an on-demand fashion the latest technologies on multiple clouds. Today they were using AWS cloud and OpenStack, but tomorrow they wanted any cloud that matched their workload configuration needs best.

      •  

    • IT operations and system admins brought up their set of challenges. Their primary goal was to configure environments for repeatability; safeguard builds from failures and structure stable workflows. Not an easy job come to think of it. On top of this demands from the engineering teams dictated that they learn and implement new technologies in a very short time. Technologies ranged from configuration management tools, cloud platforms, storage, networking, load balancing services, monitoring services, and more. Besides when engineers wrote configuration templates as Enogo did for AWS, it was hard to figure out who owned the deployment stack. In the case of problems, it resulted in pointless blame games. So they desired a clear level of separation between code, deployment automation, and infrastructure. Technologies and cloud platforms could come and go, but IT operations remained responsible to maintain smooth workflows, stable builds, and error-free deployments.
       
      A service catalog also met the needs of the IT operations teams. They wanted to build and manage specific platforms, runtimes and version configuration changes. Collaboration was a key factor. Many IT operations team members and engineers were experts in some but not all technologies and tools. But together in a collaborative platform, experts could contribute at their skill level and share knowledge with others. Automating configuration changes in bulk saved a ton of time. Therefore, API support for automation was high on their wish-list.

      •  

    • The IT managers were important though indirect stakeholders. They often approved and handled audits, compliance, and budgetary aspects. Policies and cost management were paramount to them. IT managers needed control and oversight to implement compliant deployment policies that gave the right level of access to the right set of infrastructure on pre-approved cloud providers. They needed to set and monitor quotas and track IT spend on cloud deployments against approved budget.

    Transformed enterprise

    After three months of evaluating proof-of-concept solutions with vendors, they zeroed in on a solution that met all of their uses cases and helped set up their current builds. Because of this, the teams were able to ship code ten times faster. It was only a matter of time before D-Chip stood out as a market leader. It was clear to the company executives what was driving this transformation.

    They retired the semiconductor business and switched their business focus entirely to SDK builds of software for wearable computing. The software services for wearable chips was now way more valuable than any piece of hardware. Their customers in wearable computing now consumed D-Chip technology as a service in the cloud. A faster and efficient software development lifecycle enabled them to carve a new market niche and become the de facto leader.

    The transforming story of D-Chip is a reminder for us all. When there are problems in software development, by aligning goals and helping people in different roles work together and participate in the development lifecycle, you increase the pace of innovation dramatically. It can be so powerful that it can transform the company’s core products or services.

    Disruptive change doesn’t happen one step at a time. It happens with mavericks and innovators like Rachel and Chandler leading radical changes in a focused group effort. You want innovation to transform your business? Get a dedicated group of mavericks together and make it happen.

    Just like mankind advanced their understanding through each cycle of civilization from the stone age up to the Renaissance and the Industrial Revolution, the future is heralded by the IT age of our times.

  • The One Where All the Deployments Stall

    The One Where All the Deployments Stall

    In the first episode of the DevOps story, DChip CEO Phoebe gave Chandler an ultimatum to move out of AWS into their datacenter on OpenStack. Does Chandler succeed? Read on to find out…

    Fast forward two weeks since that fateful night. Chandler is preparing for yet another leadership call. It’s deja vu, with the same story all over again. Only this time he knew the problems all too well. So he sat bleary-eyed and prepared what to say.

    Time to face the music

    The meeting involved the usual suspects. Phoebe, Monica dialed in from the US along with the sales and marketing VPs and Janice the VP of Finance.

    Strangely, or maybe it was the late hour of the night, Chandler felt calm as he spoke:

    “I want to bring everyone up to speed on the progress to shut down AWS and move to OpenStack in our datacenter. We have bad news. Enogo engineers were not able to migrate workloads to OpenStack smoothly. The problem is such that they have not managed to release a single update, and the release schedule has started to slip.”

    Both Rachel and Joey eyed him sharply. He wasn’t going to back down from the truth now, so he ventured: “Engineering sprints are delayed because of this. The real problem is the OpenStack environment. It’s not mature. Most IT operations engineers are still learning to configure it, and there are many environment issues. I understand, everyone is going to hit panic mode. Which is why, I say, we keep AWS Cloud to return to business as usual.”

    Soon as Chandler finished, the finger-pointing began.

    “Enogo engineers used CloudFormation templates in AWS for dev/test/staging deployments. Those templates, however, don’t work in OpenStack because Heat is not set up properly,” Rachel said. Adding, “We sent the templates to the Ops team, but they never got back to us.”

    “Well, when the templates are not written correctly by the developers,” countered Monica, who headed the OpenStack implementation, “we have to rewrite them from scratch in Heat. That’s not going to happen overnight, is it?”

    All the while, Phoebe, who’d hardly said a word knew that Chandler was right. The 3-month transition plan to OpenStack was too aggressive and just not practical. If more and more developers choose AWS cloud, why not join forces if we are to help them succeed?

    As a leader, you have to know when you’re wrong and correct course. So she did. “Chandler is right. We should go back to AWS to avoid schedule slippages and get the release back on track. I will discuss a longer term plan with Chandler.”

    We need a solution

    After everyone except Chandler had dropped off the video call, Phoebe said: “Look, we f*****d up. We can’t go through another f***k up and face this kind of deployment shutdown. We need a solution and fast. What do you say Chandler?

    “I can’t agree more. To minimize business risks and integrate both company systems, we need a hybrid solution that supports deploying to both AWS and OpenStack clouds. It’s not enough to simply solve for the template problem of today. It should scale for future projects. We need a solution that offers a single point of management for both clouds. The Enogo team should be able to deploy with the same speed and ease of AWS in OpenStack and not rely on IT Ops to hand-hold them.

    “Bingo,” said Phoebe at last smiling.

    The next morning as Chandler stirred his coffee trying to awaken his still asleep brain, he read this email from Rachel:
    “Hey Chandler, a couple of engineers have already written a bunch of scripts to automate deployments in AWS. I say, we devote a few more engineers and build an org-wide solution that will enable us to build and deploy in both clouds. What do you think?”

    How timely, thought Chandler. So Rachel, the Enogo engineering manager wants to build the solution in-house with her team of engineers. She wants five engineers and six months to do it. This project will no doubt widen her impact and visibility in the company. Good for her!

    Chandler sent a brief, “Why don’t we discuss in person tomorrow,” reply. In walked Rachel the following afternoon. The minute she saw Chandler’s face, her enthusiasm took a dive. He doesn’t look amused, she thought. His steely gaze sent a chill up her spine.

    Wait to see what happens in the next installment of the DevOps story coming soon from ElasticBox.

  • The One Where All Hell Breaks Loose

    The One Where All Hell Breaks Loose

    Don’t you love a good story? This one is a DevOps story in a fictional enterprise. It’s the kind of story you’ve seen replayed countless times in large organizations. So settle in for a read.

    The backstory

    DChip Tech is a semiconductor company. They’re in the business of making chips for wearable computing since acquiring Enogo, a startup in France for simulated testing in wearable technology.

    Three months into the acquisition on a late Sunday night in France, the VP of Operations at Enogo considers his late evening ahead.

    Chandler is not a happy man despite his recent appointment as the VP of Operations. How can he be? How can a 40-person company in France give him so many sleepless nights? And tonight is no exception.

    DChip’s strategic momentum in the last months had everything to do with it. To leverage the cream of the crop engineering talent in wearable tech, DChip, the San Francisco Bay area chip giant invested in Enogo.

    • Now DChip wants Enogo systems fully integrated into its OpenStack datacenter to reduce infrastructure costs.
    • Although Enogo hosts on AWS, DChip doesn’t want to integrate AWS Europe into the corporate network. They want to keep the intellectual property in the US.
    • It falls on Chandler’s lap to integrate the systems of both the companies and reorganize IT, to speed up DChip releases from once every six months to the weekly push like at Enogo. Imagine all that.

    Tall order, he thinks wryly, gulping down another cup of coffee to keep him awake for the Monday morning US time leadership meeting.

    Where all the action happens

    He dials into the video conference warily, his head already starting to throb. First to appear on the screen, Phoebe, the CIO is looking none too happy either. Soon all the division heads appear on separate screens including the engineering and QA heads from Enogo.

    Dismissing the usual small talk, Phoebe launches right to the point. We have a firm deadline to move out of AWS cloud in three months. Yet, where do we stand now? Can someone explain why the delay in integrating the systems of both companies? Do you know how much this is slowing down our go-to-market strategy?

    Monica, the Chief Architect in charge of the Datacenter OpenStack cluster, says, “We’d love Enogo to move to OpenStack today. But it’s not fully stable.”

    As if to emphasize the point, Rachel the engineering manager whose team is building the wearable emulation test software adds, “We can’t wait for the OpenStack cluster to work. Our engineers need test environments like yesterday. That’s why using AWS makes sense.”

    The marketing and sales VPs quietly watch as everyone joins in the blame game.

    Not to be left out, Joey the Enogo QA Manager complains that he can’t deploy the image that contains the emulation software because OpenStack is corrupting it. “All the more reason to support AWS,” he quips.

    The ultimatum

    I’ve heard enough; Phoebe bellows over the din of the meeting. She turns slowly to glare at Chandler through the video camera. “Chandler, do you care to explain why we have an unforeseen $100,000 dollar expense this month? I want an explanation.”

    “It’s a case of a simple, human error; it can happen to anyone Phoebe,” Chandler tried calmly to explain. “One of the devs launched instances and forgot about it until we got the bill.”

    “Yea” piped up Janice, the VP of Finance. You’ve been paying the AWS bills out of your credit card, Chandler, and then billing the company after the fact,” she so helpfully points out.

    Chandler stands dumbfounded as Phoebe’s final words struck his heart: “I told you to shut down operations on AWS. I want to move to our datacenter on OpenStack. No more bills from AWS Chandler, you hear me?”

    Her words rang late into the night and the next day.

    To be continued…

    (What do you think will happen next? Watch this space for our next episode of the DevOps story. Any resemblance to these characters or events in real life is purely coincidental.)

  • User pragmatism is stronger than ever

    User pragmatism is stronger than ever

    This is the third of a series of posts about why we thought the world needed another DevOps oriented company and so invested in and started StackStorm.   I hope we are touching on general themes that can help others understand the rapid disruptive shift towards DevOps approaches to building and operating technology.

    When starting StackStorm we were inspired by OpenStack.  This week is the OpenStack summit and we are contributing heavily to some pieces of OpenStack, so we remain enthusiastic community members.  However, our third reason for StackStorm has to do with how we lost our naive perspective on OpenStack and understood it more as a symptom of a new, more enlightened approach to technology selection, development and operation.

    OpenStack is important – however, users are more pragmatic and agnostic than ever.

    OpenStack is the full stack plus, plus, plus; it is very different than almost every other open source community thanks to its breadth, from storage through networking, security, compute, management and more. Not surprisingly, OpenStack is a massively diverse community. And it has unstoppable momentum. However, when we went to interview practitioners we consistently saw that the DevOps savvy see OpenStack pragmatically. The operators we know see OpenStack as a means to an end.

    To that point, a group of about 30 operators of OpenStack were recently asked at the OpenCompute 2014 summit in San Jose – what distribution do you use? There are of course many, many distributions and there has been talk of a distribution war. So we were really interested in the answer – who are these operators using?

    The answer – NO ONE. Top operators are taking the bits they need. While RedHat and presumably others will succeed over time in selling support for a distribution, I don’t think most commentators really understand to what extent the DevOps mindset alters the equation for legacy open source models as well as, of course, legacy proprietary models.

    A DevOps operator, generally speaking, takes the pieces that make sense and then ties them together so that their operations environment, their hybrid cloud, their software defined data center, are truly theirs and operate together as one system. To avoid accidental lock in, maintenance burden and technical debt, each of the many, many, many pieces that together comprise a DevOps environment are themselves almost always open source and broadly deployed by others. This way the operator avoids lock in while also having what they need for their business.

    So – open source and specifically OpenStack pieces are fundamental to the operators we know. However, through formal and informal communities these operators are now empowered to take the best of breed components and integrate them into a whole. And what does this get them?

    Refer back to an earlier post – this approach is delivering 10x-100x productivity improvements, which means a chance to stay in business because if you don’t make this transition and your competitors do, they will cycle faster than you closer and closer and closer to the customers.

    This brings me to a discussion of DevOps architectures. How can you tie together so many loosely coupled pieces? Does the Legos analogy stand up? Yes it does. More on that soon.