devopsy.kinsta.cloud

Tag: faster development

  • The Definition of Faster in the Age of App Capital

    The Definition of Faster in the Age of App Capital

    Businesses want speed. One of the impacts of digital transformation—and the associated pressure to succeed in an app economy—is the desire to move at speed. Nearly half (48%) of organizations are driven by digital transformation to deploy faster according to our State of Application Services 2019.

    But it’s not all about deployment. It’s also about development and responsiveness to threats and changes in demand.

    Organizations want to develop and deliver apps faster. They want to adapt to unpredictable changes in business conditions faster. They want to respond to attacks faster.

    So, how are they going to get it?

    Faster Development

    Deploying more frequently implies you’re first developing faster. That often means adoption of speed-oriented Agile methodologies. GitLab’s 2019 Global Developer Report: DevSecOps found that the majority (54%) are choosing Scrum, while 37% go for Kanban.

    Componentization

    Methodologies aren’t enough if application architectures aren’t well-suited to development styles. Smaller, focused teams sprinting toward frequent releases isn’t really a good fit for developing new features or fixes for traditional and monolithic applications. Componentization through the adoption of microservices and more distributed forms of architecture fit more naturally with modern architectural and operational principles. It’s no surprise that, on average, more than 80% of a modern application is made up of third-party components, heavily weighted toward open source.

    APIs

    Adoption of APIs, as well, is no surprise amongst those seeking faster development through componentized application architectures. APIs decouple implementation from interface and allow teams to make modifications to processing without impacting the use of APIs from other components or applications. This is a common pattern, with an impressive 64% of organizations creating APIs today for use in either internal or external use cases. Nearly 50% of those organizations rely on APIs to get ideas to market faster according to Jitterbit’s State of API Integration 2018.

    Automation (CI/CD)

    The build pipeline, too, has to keep up if frequently deployment goals are to be met. That means CI/CD tools that seamlessly move code from commit to test to release. The most popular CI and build tools in GitLab’s survey were, unsurprisingly, GitLab (61%) followed by Jenkins (36%) and Travis CI (12%). Notably, our own research finds Jenkins in use by 16% for network automation as well—a promising result if organizations are seeking to extend DevOps beyond delivery into deployment.

    Faster Deployment

    Developing faster doesn’t get ideas to market faster. That requires deployment. While born-in-the-cloud technology companies have mastered the delivery-deployment divide with ease, many established enterprises find this transition challenging. Existing organization structures as well as the continued need to support traditional and monolithic applications introduces conflicts that can be challenging to integrate with modern operational demands. But there is no doubt that organizations must overcome these challenges for those applications requiring faster and more frequent deployments.

    Continuous Deployment

    Don’t be fooled; established organizations are embracing automation and applying it to the deployment pipeline. The issue is often that traditional IT structures introduce inconsistent automation and self-service efforts. We see this play out in our own research, where strongly siloed team structures continue to impact automation efforts across IT.

    Team structures matter and organizations whose compass is pointed at automated pipelines will need to address the cultural aspects of continuous deployment if they want to consistently deploy faster.

    Public Cloud

    Traditionally, the inability to achieve continuous deployment has pushed developers and app owners to turn to the public cloud, because it eliminates the obstacles in the slower, enterprise deployment path. The disparity in opinion on frequency of deployments is, in part, a contributor to the issue. Our 2018 NetOps/DevOps survey found that while 55% of DevOps and 52% of cloud architects felt their organization did not deploy frequently enough, only 30% of NetOps and the same percentage of operations agreed. 

    But it’s not the only driver. Digital transformation is certainly a factor; 33% of respondents in our State of Application Services indicated they are intentionally moving to deliver apps from the public cloud as a result of embracing digital transformation initiatives. The ability to easily integrate application services and subsequently automate operation is a huge boon to organizations seeking a faster route to frequent deployment.

    Containers

    In the cloud—but also on-premises—continuous deployment often requires the ability to adopt per-app pipelines and application services that support the model. Increasingly, organizations are turning to containers because of their ability to support rapid updates and operate seamlessly in highly volatile environments. We see containers in demand not only to support modern application architectures such as cloud native—the top container use-case at 33% of respondents to Diamanti’s 2019 Container Adoption Benchmark—but also for infrastructure. The demand for on-premises application services in containers has consistently grown year over year in our own research, rising from just 4% in 2017 to 15% in 2019.

    Faster Responses

    Not everything is about delivery and deployment. Organizations also need speed when it comes to security and operations. In today’s world, where more than half of all app interactions are conducted by bots, it’s important for organizations to respond quickly with a reject message to avoid falling prey to exploits or infection. 

    Real-Time Threat Analytics

    One of the ways organizations are seeking to speed up their ability to respond to attacks is through the adoption of real-time threat analytics. With security continuing to be a top priority and consistent challenge, it was no surprise to see this category ascend into the top five strategy trends and technology in 2019 with 41% of respondents tagging it.

    The availability of intelligent security application services will accelerate as machine learning and automation continue to apply their considerable capabilities to the problem of identifying troublesome traffic faster.

    Orchestration Included

    Machine learning isn’t the only way in which infrastructure and application services are getting smarter. As the need for faster responses to capacity and processing grow along with users, infrastructure and application services are evolving to include orchestration as a core capability rather than an add-on. Application service platforms with integrated orchestration layers will mean services that scale along with demand—on-demand. While such capabilities exist today—indeed, they are part and parcel of cloud and containers—the capabilities to automatically scale up and down based on application and user defined requirements is not native to most systems today. But they will be.

    Faster Identification of Bad Actors

    Finally, organizations need to combat bots for both business and security purposes. Whether organizations need to stop scraping—a real threat to business—or prevent bots from probing for vulnerabilities, identifying bad bot actors faster is critical today. Checking a box (I’m not a robot) isn’t enough today as bots are growing more intelligent and are able to foil such primitive techniques.

    Organizations are turning to Bot Defense services capable of applying more modern, successful techniques to quickly identify and block bad actor bots. We’ve seen the use of bot defense services grow quarter over quarter in response to this need, and expect this trend to continue.

    Faster Development, Faster Deployment, Faster Responses

    When it comes to business’ need for speed today, we wind up looking at processes. Development processes are automated to gain speed with CI/CD. Deployment processes are automated to gain speed with continuous deployment and cloud. Scaling and security processes are being automated by systems and the introduction of orchestration as native to application service platforms.

    Faster, it turns out, relies on an organization’s ability to automate processes across development, deployment and security. 

    — Lori MacVittie

  • The Disposable Development Environment

    The Disposable Development Environment

    Wait! Just wait a dadgummed minute! It takes days to build a development environment, and now I am supposed to read an article on a disposable development environment?

    Yes.

    It seems like it took an entire sprint to upgrade PHP! Now I am supposed to let them build something so they can trash it?

    Yes … yes, you are.

    Disposable DevOps Thinking

    DevOps is based on five pillars:

    • Culture
    • Automation
    • Lean Thinking
    • Measurement
    • Sharing

    Because we automate environments such that they are easy to share, we should be able to measure meaningful business impact. This model is a DevOps practice of modeling developer workflow for operational tasks.

    Why a Disposable Development Environment

    Log in to your workstation and delete the runtime for Java, PHP, etc. Remove, or change, a few config files and empty the trash. Now what? What if your entire team did this because they had a great idea? Panicking yet? What if getting started in any team was as easy as:

    • Cloning the project from source control
    • Starting the runtime environment
    • Obtaining caffeine
    • Getting to work

    The majority of developers today have a hand-built, artisanal, bespoke workstation setups with the following characteristics:

    • It takes days to onboard a new team member.
    • Innovation around runtime environments is stifled.
    • Moving from one team to another is the work of days.
    • Workflow is more like Ops instead of Dev.

    Let’s set some goals:

    • No more than 30 minutes for a new team member to make their first code commit.
    • No more than five minutes to throw away an environment and start over.
    • No more than five minutes for a developer to move from one team to another.
    • Runtime changes happen the same way as application changes.

    None of this is possible unless your teams can throw away a runtime environment at will, thus disposability is an “[-ility]” that we should expect to be delivered with our software.

    Disposable is Indispensable

    The most important concept is handling runtime of the application with a virtual machine (VM) on the workstation. The application code remains on the workstation. This means that developers still use all the tools and workflows they have today. If a mistake happens on the VM, kill it and start over. If it happens on the workstation, then its time to rebuild the laptop.

    At its core, the ideas borrows from common concepts in our production environment (and a specific tool example):

    • Hypervisor for supporting guest virtual machines on the workstation, such as Virtualbox
    • Provisioner to configure the guest machine, such as Chef
    • Source Control to track and manage changes to the application and the configuration, such as git
    • Glue so the provider and provisioner can be expressed as code and managed through source control, such as Vagrant

    Onboarding a New Team Member

    Have the new employee follow a set of directions. It should take no more than 30 minutes for the employee to install the tools and the application he or she is to work on. As a manager, this must be measured and tested relentlessly. New hires should be directed to keep notes on trouble spots and anything that takes a long time. They improve the documentation for the next new hire.

    Accelerate Innovation

    Developers say, “I wish I could upgrade to PHP X! I would be done in minutes, not days!”

    Developers are capable of such an upgrade, so the real problems are:

    • It takes a few hours to upgrade a language version.
    • If the attempt fails, it could be longer to unravel all the hand-rolled changes.
    • If the attempt succeeds, everyone on the team is committed to undertake a fraught journey to upgrade their bespoke workstation.

    With management asking about things such as feature velocity, time to value and internal hurdle rates, who is willing to take that sort of time only to succeed and cause everyone else on the team grief, too? This is why security upgrades are always done with such pain. They are delayed because they are “non-functional.”

    Now abstract the runtime to a VM and the configuration of the VM to code. Assume the developer wants to upgrade PHP.

    • Developer destroys the current VM with PHP 5.2.6 on it.
    • Developer goes into the Chef code (for example) and changes the PHP version to 5.3.29.
    • Developer launches a new VM with a single command.
    • Developer runs automated tests.

    The most likely outcome is some tests fail. With a bespoke environment, this is where the upgrade effort stops. Fixing all the tests is a commitment to getting the entire team to move in lock-step. On a team of just five people this is daunting. Developers are not project managers.

    With a disposable development environment, it takes five minutes to make the change. Developers know it is an identical effort for their colleagues, so the thinking changes.

    Given an arbitrary time window, the tests are fixed and the PHP upgrade saves the time or improves system performance or patches a security hole. To share this change across the team this same developer commits the change in the Chef code. They push it to the code repository and message the team, “Hey PHP 5.3.29 works, please adjust.” One person does all the work.

    Team members stop what they are doing. They stash the work they have inflight. They pull the changes from the code repository. They start the VM and Chef configures it. They unstash their work and get back to providing business value. In less than five minutes the entire team is done.

    Accelerate Security and Compliance

    What if a developer’s upgrade causes security issues? Changing something as important as the language version is meant to illustrate this power. But this is not the right question to ask. Instead, ask this one, “How do we ensure we are secure before we get to production?”

    Assume that any change in the development environment is reflected in production through the same process. For example, when code is deployed to quality assurance (QA), the Chef cookbooks run and they bring up the machine with the new PHP version. Why would there not be tests to show that the application is at least as secure as previously?

    Even more to the point: By making it easy to upgrade the base language, test the change and share it across the team, upgrades are much less risky.

    This thinking has some new assumptions:

    • You trust test automation at the application level. (common)
    • You trust the test automation at the infrastructure level. (uncommon)
    • You have automated security and compliance practices that check before a production release. (rare)

    As managers we must help our:

    • Ops team becomes better at the practices of code management since the infrastructure will be code.
    • Development team makes responsible changes in concert with operations, security and compliance groups.
    • Security teams adopt a security-as-code mindset to facilitate testing before promotion from development.
    • Compliance team joins the development effort so changes are already part of audit output. Compliance-as-code is already on the way.

    Business Outcomes of a Disposable Development Environment

    We hire new people when we need them. Taking two weeks just to get into a working state means we are delaying time to value. Delaying 30 minutes is less time than filling out the HR paperwork. We need this critical time to fill the need that caused the hire.

    Developers have more freedom in the infrastructure to try their ideas. The also have the safety net of putting it back like it was in less than five minutes when the idea does not pan out.

    Patches to the runtime environment for security can be applied at development time where they can be tested through the full deployment cycle. This takes minutes instead of days.

    If all teams are using a standard method and tool chain, then it is possible to adhere to the maxim, “Put your best people on your biggest opportunity.” Developers can move from Team A to Team B in less than five minutes and get started learning the code. They can move back in the same five minutes.

    Changes in the runtime happen at development time, and they are promoted and release with the application. So, perhaps most of all, if it works on the developers laptop then it will work in production.

    Without the ability to simply throw away the environment and easily start over, Dev and Ops cannot innovate toward these benefits. So go ahead and dispose of those bespoke workstations, and be sure to manage toward the benefits:

    • No more than 30 minutes for a new team member to make their first code commit.
    • No more than five minutes to throw away an environment and start over.
    • No more than five minutes for a developer to move from one team to another.
    • Runtime changes happen the same way as application changes.
  • Mixcloud Makeover: Faster Development, More Confidence

    Mixcloud Makeover: Faster Development, More Confidence

    “Mixcloud provides audio hosting and distribution for millions of podcasters and DJs,” says Matthew Clayton, CTO & Co-Founder, Mixcloud. Mixcloud’s developers program the site in python (Django) and javascript, and develop their native mobile apps in Java and Objective-C. The Mixcloud team grew its mammoth Django monolith application over a five year period. Mixcloud’s primary server infrastructure supports this application, which makes up most of its code base.

    The Legacy Development Workflow & Goals For The Future

    The Mixcloud team used to code its application on a branch, deploy the branch, check for stability, merge it into the master branch and redeploy it. “We used to branch the code on git, then push this to github so that all the team could see the branches developing in parallel,” says Clayton. To check code stability, the Mixcloud team used to simply watch to see whether the site crashed on a single server. “We originally didn’t have any tests, so this was really the only way we could see whether there was a problem,” says Clayton.

    The old overall development methodology also produced challenges every time Mixcloud hired new developers. “Adding developers who didn’t understand the entire stack massively increased the likelihood of bugs and the risk of downtime,” says Clayton.

    When Mixcloud went looking for a DevOps / continuous delivery approach, it had in mind to increase the quality of the code its developers produced and to increase the team’s confidence in the code they shipped to production while overall having faster development.

    New Workflow, Bumps In The Road

    Today, Mixcloud hosts and reviews its code using github.com. The company uses Slack for internal communications. The team uses getsentry.com for exception handling and Asana for product feature and bug tracking. “We use Codeship for running Linting (python/JS/Templates), JS unit tests, Python tests, Selenium integration tests, and database integration tests,” says Clayton.

    Python/JS/Templates enable code linting by leveraging tools such as pylint, jslint, and Django-extensions to perform static analysis and to lint the appropriate code.

    But the path to DevOps enlightenment and improvements is never ending. It took some time for Clayton and his team to understand how all the working components affect each other as they integrate together. “We still have not included database migrations in our release process. This is still a manual process,” says Clayton. Mixcloud will eventually add this too to its list of automated endeavors.

    Navigating The DevOps / Continuous Delivery Maze

    At the very start of a round trip through the new development process, Mixcloud developers will open up a pull request on github.com and assign it to another team member. This action automatically sets a complete build in motion and deploys a staging infrastructure. “The assigned developer will now review the pull request using github, and also the running code. Once this review process is complete, the branch merges with the master,” says Clayton.

    This will next set off a deployment in production. When the team is ready, they will run a single command to activate the new code for each and every user. “The whole test and deploy process now takes about three minutes. This enables a rapid iteration,” says Clayton.

    Benefits & Surprises

    Two of the biggest benefits for Mixcloud were adding code linting and pull request reviews. “These helped the team become more aware of changes across the entire code base, and eradicated entire classes of bugs for what is essentially a fixed, one-off engineering cost,” says Clayton.

    When compared with the legacy development methodology that could introduce new bugs every time a new developer came on board, the Mixcloud team now only introduces bugs of a magnitude that could create website outages and downtime in the rarest of cases.

    But the major unpredicted upside was how the automation and the reduction in manual testing added to the productivity and development speed. “Surprisingly, there have been massive improvements to interaction speed among team members. We are seeing productivity and developer happiness that are significantly better than before the change,” says Clayton. The ability for the development process to refactor huge amounts of code with confidence has also made great strides forward.