devopsy.kinsta.cloud

Author: Lars Cromley

  • AWS re:Invent 2018 Product Launches: An Overview

    AWS re:Invent 2018 Product Launches: An Overview

    AWS re:Invent is always rich in product launches. Some products are entirely new, while others are updates or enhancements to existing tools. The 2018 event was no exception. In case you missed it, here’s a drive-thru on some of the best products—and one important statement—from this year’s show.

    AWS Marketplace for Containers

    Announced at the Global Partner Summit keynote, the AWS Marketplace for Containers is the next logical step in the Marketplace ecosystem. Vendors will now be able to offer container solutions for their products, just as they do with AWS EC2 AMIs. The big takeaway here is just how important containerization is and how much of a growth we see in the implementation of containerized products and serverless architectures in general. Along with the big announcements around AWS Lambda, this solidifies the push in the industry to adopt serverless models for applications.

    AWS Marketplace – Private Marketplace

    The AWS Marketplace has added the Private Marketplace to its feature set. You can now have your own marketplace that’s shared across your AWS organizations. This is neat and all, but I think what’s even more interesting is what it hints at in the background. It seems to me that to have a well-established marketplace at all, your organization needs to begin its journey on the DevOps trail. This news shows that a good deployment pipeline is really the best way to handle a project, for both external and internal customers.

    Firecracker

    This looks really cool. Firecracker is a virtualization tool that is built specifically for micro VMs and function-based services such as Lambda or Fargate. It runs on bare metal … wait, what? I thought we’re trying to move away from our own hosted servers? That’s true. However, consider all the new IoT products and features that were announced at the conference and you’ll see there’s still a lot of bare metal, both in use and in development. I don’t think Firecracker is meant solely for large server farm-type setups, but quite possibly for items in the IoT space. The serverless/microservice architecture is a strong one, and this allows that to happen in the IoT space. In fact, I’m currently working on installing it onto my kids’ Minecraft microcomputer.

    Andy Jassy Says What?

    In the fireside chat with AWS CEO Andy Jassy in the partner keynote, there were several things I found interesting. But one comment stood out from the rest:

    I hear enterprises, all the time, wanting help thinking about how they can innovate at a faster clip. And, you know, it’s funny, a lot of the enterprise EBCs I get to be involved in … I’d say roughly half the content of those are enterprises asking me about our offering and how we think about our business and what we have planned in the future, but a good chunk of every one of those conversations are enterprises trying to learn how we move quickly and how we invent quickly, and I think that enterprises realize that in this day and age if you are not reinventing fast and iterating quickly on behalf of your customers, it’s really difficult to be competitive. And so I think they want help from you in how to invent faster. Now, part of that is being able to operate on top of the cloud and operate on top of a platform like AWS that has so many services that you can stitch together however you see fit. Some of it also is, how do people think about DevOps? How do people think about organizing their teams? You know … what are the right constraints that you have but that still allow people to move quickly.

    He said DevOps! Apparently, larger companies that are looking to change don’t just want fancy tools and new technology. They also need help getting better at effecting change. That’s absolutely outside the wheelhouse of AWS, and clearly a call-to-action for the partner community.

    — Lars Cromley

  • Manual Processes and Silos Complicating DevOps Deployments

    Manual Processes and Silos Complicating DevOps Deployments

    The DevOps concept largely originated in 2009, as software and IT organizations were beginning to adopt Agile methodologies. It came on the heels of a movement to integrate lean manufacturing concepts and infrastructure as a service into IT organizations. Rapid development was the goal, but application and infrastructure teams were still working independently, creating barriers to progress. Flickr employees John Allspaw and Paul Hammond delivered a presentation at the O’Reilly Velocity Conference that outlined ideas for streamlining deployment through better collaboration between development and operations. They hoped to temper conflicts between team members and minimize waste. DevOps took off soon after, when Patrick Debois founded the DevOpsDays conference in Belgium.

    When DevOps is a mature practice in IT and software organizations, there are some powerful benefits:

    • Every change to the application stack triggers a new deployment.
    • Deployments become easy and not a fire drill.
    • Fixing errors in production become a simple redeployment without the need to perform a huge root cause analysis up front.

    The Long Road to DevOps

    While many organizations are adopting DevOps practices and tools today, we’re still a long way from reaching DevOps maturity. Our company recently conducted a survey on DevOps adoption, and the findings indicate that there are still too many manual processes and silos standing in the way. I will break them down here:

    Manual Infrastructure Management is Still Common 

    Nearly 40 percent of IT professionals surveyed say that they manage infrastructure manually. Yet nearly 60 percent report the use of infrastructure-as-code tools such as Terraform, configuration management and Kubernetes. This speaks to a disconnect between having the technology available to operate in an automated way and being able to execute change with those tools. Heavy manual processes lead to higher costs, since so much effort goes toward tinkering with configurations and fixing problems. Manual work also detracts from the ability to members to focus on the application and business needs.

    Managing Environments in Silos

    Another tenet of DevOps infrastructure management is environmental parity. This means that through infrastructure-as-a-code tools and processes, IT manages all development environments similarly through a common code base. According to the survey, only 25 percent of companies are managing development, test and production environments identically. This results in application stability issues. Without environmental parity, every change will eventually lead to an outage.

    Managing Teams in Silos

    From the start, DevOps has emphasized breaking down the walls between development, QA and IT operations. The goal is to enable continuous feedback, fewer errors and faster development cycles. Of survey respondents, 78 percent report that separate teams are still managing infrastructure/operations and application development. As well, just because you create a DevOps team consisting of various job roles doesn’t mean that people are working together and are committed to the team’s success.

    There must be incentives to encourage a developer to understand testing needs and for infrastructure engineers to get clear on a project’s requirements and objectives. There should be minimal tolerance for functional experts isolating themselves without making an effort to understand the bigger picture.

    When organizations are able to minimize manual processes and break down these technology and silos, they benefit from a totally different, more productive way of working:

    • Adoption of continuous integration/continuous deployment, whereby every code check-in triggers a testing cycle and a build.
    • Transparency between infrastructure people and developers, avoiding surprises resulting in issues or rework later.
    • Incorporation of success metrics, such as deployment frequency, mean time to detection (MTTD), mean time to recovery (MTTR) and change lead time.
    • Cost reduction, from fewer errors and labor-intensive manual processes.
    • Increased productivity, as developers get the infrastructure they need quickly to run new projects and QA and IT Ops people can focus on high quality, stability and user experience rather than repetitive tasks and troubleshooting.

    So, What’s Going On? 

    Despite the many benefits of DevOps, there seems to be a lack of urgency in some organizations to take the necessary steps for change. Progressive IT departments that applaud agility and business value should be ahead of the curve, but that’s not always the case.

    DevOps maturity comes down to setting the right culture for change, which must emanate from the top. The shift to DevOps takes time and investment, no doubt. There’s also need for patience. The transition temporarily slows down production as people adjust to new workflows and learn new skills. Replacing toolsets is just part of the strategy. Organizations must make a conscious effort to embrace DevOps with a well-thought out plan.

    — Lars Cromley