devopsy.kinsta.cloud

Author: Mrina Natarajan

  • Secrets to win over DevOps buyers

    Secrets to win over DevOps buyers

    In its recent report, Tech Go-to-Market: How to Win With DevOps Buyers, Gartner Research looks at the buying process of DevOps-centered organizations. And Gartner makes an important point. For technology providers to sell to organizations with a DevOps culture, traditional sales approaches don’t fly. In fact, developers and operations teams—whose synergy we collectively call DevOps—eschew traditional marketing and sales pitches. They are so technically discerning that they sniff out marketing lingo from a real product offering. The real danger is they can shun a product forever when it comes from marketing or sales channels. So what’s the best way to win over DevOps teams?

    Technology providers familiar with selling to traditional I&O (infrastructure and operations) teams find themselves on unfamiliar ground in a DevOps driven culture. A big change Gartner notes is that workloads increasingly migrate from the traditional datacenter to public or multi-cloud infrastructure like AWS, Azure, Google Cloud, vSphere.

    Gartner found that migrating workloads to the public cloud shifts decision-making power away from the traditional IT buyers to DevOps and agile practitioners. These personas include developers, DevOps managers, release managers, build/automation managers, and architects who influence buying decisions bottom-up. Moreover, DevOps philosophies and practices vary so much from one organization to the next that IT providers are at a loss to clearly chart the buying process.

    Three ways to engage with DevOps teams

    What’s the best way to influence DevOps teams? Gartner explains that for marketers and sales teams to build credibility, they must show that the product increases business value. For DevOps teams to embrace a product, Gartner lists three requirements.

    1. Easy product access. Give DevOps teams wide access to your product functionality upfront. They must experience to believe its value, so give them full or close to full functionality in SaaS or on-premises via freemium, open-source, or a free trial.
    2. Robust API capabilities. A robust API addresses these questions: Is it public, easy, RESTful, well-documented? Does it have an active or growing community of users? Are there samples to get started? Are most of the features exposed via API? Finally, are the latest and future API backward-compatible?
    3. Key tool integration. According to Gartner, DevOps teams use a spectrum of tools to automate the full lifecycle of developing, delivering, and maintaining software whether in the cloud or on-premise. The product must, therefore, integrate with a variety of popular and open source DevOps tools like Chef, Puppet, SaltStack, Ansible, Docker, Jenkins. It is in this light that Gartner credits ElasticBox as a strategic partner for DevOps focused organizations.

    Above all, the product must enable the DevOps transformation of the enterprise. Take DeNA, a Japanese gaming company for example. Game development teams across geographies need build environments for new games. Typically, they opened a ticket with the operations team in San Francisco and waited. It’s not that the operations team couldn’t service them quicker, it’s just that they prioritized maintaining a stable, secure production environment and justly so. DeNA today automates its software development lifecycle using the ElasticBox platform. IT operations decentralize build requests and empower developers to self-service environment provisioning through our solution. Development teams pay as they use cloud resources to launch build game environments on-demand for development, test, staging, and production. As one developer put it, we were able to dramatically increase the build efficiency from 2 weeks to 5 or 10 minutes.

    All told, DevOps tools must help organizations increase business value by innovating faster and accelerating software delivery. It is for this reason that organizations practice Agile and DevOps methods in the first place. To appeal to the DevOps teams, Gartner says non-traditional methods help. That means being present and engaging in DevOps communities, with peers, and independent experts to influence buying decisions. To read Gartner’s full report and get insights into the DevOps buyer’s mindset, see Tech Go-to-Market: How to Win With DevOps Buyers.

  • 3 golden rules of microservices deployments

    3 golden rules of microservices deployments

    As a developer, you value the principles of SOA. You aspire to build applications as a set of consumable services via endpoints. Remember how Amazon used SOA to build the AWS platform and how Google is emulating AWS? However, not all is hunky-dory in the SOA world.

    Developing is one thing but running, managing, and maintaining services is a whole other beast. When it comes to the latter, many enterprises still act monolithic. They run and manage applications services as a unit on one or many servers. This approach fails to scale when the services themselves scale or when you need to update and maintain them regularly. So do you lament over the spiking costs and time spent on these efforts or fix the problem?

    Recent trends point to microservices as the answer. By definition, microservices are much smaller than services. In fact, Wikipedia says a microservice performs a small task often just one. There are many articles that go in deep about microservices architecture, but we cover an important part here, which is deployment automation. In other words, our daily job.

    The self-contained, independent, and reusable principles of microservice architecture help solve the problem of scaling and maintaining application services.

    • Self-contained. Microservices are standalone operations that run without requiring other services. That means each runs on its own. You can scale each up or down and replace a service individually instead of updating the entire monolith given the business need and load.
    • Reusable. Microservices are self-contained so you can reuse them for other applications and functions. We’re talking of reusing already deployed microservices.
    • Independent. Microservices are platform agnostic, which means you can design them independent of infrastructure needs to run anywhere, in any cloud.

    So is it easy to shift from SOA-based architecture to microservices? Adopting microservices is not without challenges. To name some, you need to modularize existing software services as self-contained units, you need to configure the microservices to communicate with each other, and you need lots of deployment and test automation.

    To address these challenges out of the box, we recommend a DevOps solution like ElasticBox. Take a look at how ElasticBox supports microservice deployments.

    1. Modularize self-contained microservices

    The box model in ElasticBox wraps each microservice as a standalone component in a service catalog that you can reuse across applications. A script box automates the lifecycle of microservices using Bash, Puppet, Chef, SaltStack, Ansible, PowerShell; a container automates Dockerfile deploys; a CloudFormation box automates AWS resource stacks.

    2. Connect microservices via bindings

    More microservices means more endpoints to manage. Such endpoints handle REST or other protocol communications over the network. With ElasticBox bindings, network references are as easy to manipulate as programming variables. Want to route database connections to another MySQL service? It’s easy to do. Just point the services to deploy with a different binding value.

    3. Deploy microservices independently

    Boxes are inherently agnostic. Put infrastructure metadata for CPU, memory, storage, additional disks, virtual networks, firewalls, load balancing, and autoscaling in deployment policies attached to a cloud service like AWS, Google cloud, and more. Policies help you deploy the microservices defined in the script boxes to any platform and cloud. The orchestration engine in ElasticBox interacts with the cloud APIs to auto-provision virtual machines based on metadata from deployment policies. So it’s easy to spin up and destroy microservices on demand without disrupting service availability.

    ElasticBox can simplify microservices deployments. For instance the Jenkins ElasticBox plugin continuously integrates ElasticBox automation with Jenkins jobs to test and deliver what the software developments teams build continuously. So the next time you think SOA, think microservices instead.  Feel free to check out how ElasticBox can help.

  • 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.)