Recently I blogged about why managing virtual servers in the cloud is hard. Different teams have different technology and process requirements and starting points, as well as different mindsets around managing server and application instances. Meanwhile, the potential options for tooling are mind-bending. With so many variables in play, there’s no one “recipe for success” in the cloud. However, based on our years of experience in the Boston cloud consulting scene, there is a short list of 5 common cloud challenges that many teams face. Do any of these sound familiar:
One: Who moved my server? Many teams are still working with legacy infrastructure: they host their applications in a datacenter that is managed by a system administrator. As a team grows, limitations around resource availability, admin bandwidth and responsiveness to business demands become increasingly problematic. In this context, server configurations are often poorly documented and backups are ad hoc, leading to increased risk of downtime and data loss. Manual application deployments make it hard to maintain consistency across development, staging and production environments. Can moving to the cloud offer greater agility and control?
Two: Not invented here. Many teams start their move to the cloud with a homegrown cloud automation stack. But the person who created that tooling has since moved on. Remaining team members lack the bandwidth (and often the expertise) to manage and scale the customer framework to meet growing business and technical demands. Many times, about all the team can consistently do with their inherited stack is spin up new server instances. Installing new applications and tweaking configurations are manual processes that consume precious developer time. Unmanaged servers proliferate and hosting costs spiral out-of-control. How best to cut cost and complexity, relieve “technical debt” and build a solid foundation for the future… but without scrapping investments in the existing technology stack.
Three: Everybody’s different. In a lot of organizations, different teams have chosen different cloud automation tools. This leads to different “standard” tools and configurations, and applications end up hosted both in a physical datacenter and in multiple public clouds. This forces developers to spend way too much time trying to keep different environments in sync. And QA burns time sorting out the application bugs from the configuration glitches. The result is delays in releases and tense talk in the corridors. How best to standardize hosting, configurations and tools in the cloud to accelerate time-to-market for new applications?
Four: What happens in-house stays in-house. A common requirement for teams in the cloud is to keep their automation stack in-house, versus going with a Platform-as-a-Service (PaaS) platform like Amazon AWS, Windows Azure Cloud Services, Google App Engine or Heroku. Reasons for this include:
- Developers want full visibility and configurability of the stack
- A desire to avoid vendor lock-in, especially with the cloud hosting provider
- A desire to minimize security and compliance risks/issues
What are best practices for building and maintaining a custom solution? What tools will best support configuration management, application deployment and authentication in a specific environment? How best to leverage public, private and/or hybrid cloud scenarios?
Five: We’ve only just begun. Teams that are just starting their move to cloud obviously want a smooth transition leading to a new cloud automation framework that accelerates their development process. But many SMBs and startups don’t have the cloud expertise in-house to confidently choose and build out a cloud automation platform. As noted above, hiring expertise can be expensive and risky and PaaS options can abstract away your flexibility while creating vendor lock-in.