Five Insights on Cloud and Continuous Delivery Adoption

 

Five Insights on Cloud and Continuous Delivery Adoption Blog Header

Tweet This Post Button

Last month I participated in an online panel on the subject of Cloud Resources and Your CD Pipeline, as part of Continuous Discussions (#c9d9), a series of community panels about Agile, Continuous Delivery and DevOps. You can watch a recording of the panel:

Continuous Discussions is a community initiative by Electric Cloud, which powers Continuous Delivery at businesses like SpaceX, Cisco, GE, and E*TRADE by automating their build, test, and deployment processes.

Here are five key insights from my contribution to the panel:

#1: Culture is one of the biggest barriers to adopting cloud and continuous delivery.

Share-On-Twitter-Button-Tweet

Many times developers are under so much pressure from the organization to ship features that they don’t have the time to think enough about productivity, for example improving build processes, setting up continuous integration environments, or moving to the cloud. I think this is short-term thinking. Those productivity gains require a bit of upfront work, but after that you’re going to get dividends over and over again down the road.

#2: If you’re not in the cloud already, a few leading teams can give your organization a pathway to getting there.

Share-On-Twitter-Button-Tweet

While a lot of Loggly customers are cloud-centric, some organizations (particularly larger ones), have a way to go. However, I have seen the conversation change a lot over the last three years. Now, it’s not a question of if larger organizations will embrace the cloud; it’s how.

The easiest way to do it is to start small: Break out a specific team or business unit and put a specific piece of functionality in the cloud. Doing so can help that team:

  • Maintain a deployment schedule that’s independent of larger software projects
  • Iterate more quickly

#3: Hybrid cloud will make sense for certain organizations.

Share-On-Twitter-Button-Tweet

The ability to quickly test and instantly scale up your services is a huge advantage of the cloud. However, as your cloud service matures, it can be costly to pay extra for elasticity. Organizations will start looking at their use cases to determine when it makes sense to deploy on an elastic cloud, when to have reserved instances, and when to consider directly purchasing hardware. Considerations include:

  • Scalability requirements for distinct parts of your infrastructure
  • The advantages you get from key services provided by your cloud vendor, such as load balancing or content delivery networks

#4: The cloud increases the need for monitoring and logging.

Share-On-Twitter-Button-Tweet

Monitoring is really important, not only for troubleshooting but also for maintaining the operations of your infrastructure. For example, it’s important for you to know when to add capacity.

Debugging and troubleshooting capabilities also take on more importance in a cloud environment. If you find a problem in production, you don’t necessarily know what server it’s on or even whether that server is still live. With solutions like Docker, debugging is even more complex because it’s not a matter of on what server the bug occurred but in what container. You need a way to trace back information to where the bug occurred, and logging is the single common denominator that enables you to do this. Furthermore, you can’t count on just SSHing into virtual servers that may have gone away by the time you discover a problem. You should  aggregate your logs someplace more persistent than your containers or instances.

Shadow IT can drive innovation, but it needs enterprise support.

Share-On-Twitter-Button-Tweet

To me, Shadow IT means that within any IT organization, there are many different developers doing side projects, often without much visibility from their management team. These projects might involve new code, but they also can be productivity investments such as setting up a CI server. If your systems for releasing code are really cumbersome, people will try to find a way to bypass them. And in turn, you’ll find more Shadow IT spawning in your organization.

It can be really beneficial to your organization to get these types of innovative projects tested quickly. But then, once the organization sees the value in a particular innovation, how well does it get integrated into the core? How can customers benefit in the production environment? All of the support systems that your Shadow IT team has bypassed aren’t in place:

  • Test cases
  • Build servers
  • Documentation
  • Support infrastructure
  • Monitoring

I think organizations need to have the agility to deliver quick innovations, but also you need to allocate time from your organization to make them production-ready. Shadow IT again points to the importance in investing not only in features but in developer productivity and supporting new use cases.

Share On Twitter


Share Your Thoughts

Top