As most enterprise IT leaders know, transitioning IT staff to a cloud-based service delivery model is often more challenging than transitioning the infrastructure itself.
A collaborative, vertically-oriented IT organisational structure is crucial to the success of any cloud infrastructure, and yet the advice enterprises receive—usually some variation of “break down silos”—is not especially useful in an organisation with hundreds or even thousands of IT employees. A highly functional IT structure is even more difficult to achieve when the enterprise has a mix of public, private, and on-premises environments.
The vast majority of enterprises now manage hybrid clouds, and 74% of enterprises will deploy 10% to 60% of their business applications on a public IaaS platform in three years. In order for IT leaders to gain visibility across all environments and monitor, optimise, and audit all tiers of hundreds of applications, hybrid cloud environment must be managed by high-performing cross-functional teams, monitoring dashboards, and clearly defined roles and responsibilities.
Unfortunately, 59% of enterprises believe they lack the operational workflows to manage security in a cloud environment, and 79% believe they need better visibility across on-premises and cloud-based environments, according to a recent study. The question is, how? What team can adequately manage a hybrid cloud, with which processes?
A greater breadth of experience and flexibility is required of each IT employee than ever before, yet the progress of implementing the latest deployment and integration best practices is often slow. It is also challenging to find staff that understands the challenges of both traditional IT and cloud computing and can implement and monitor security and deployment strategy across both. This is why enterprises usually hire a managed service provider (MSP).
Unfortunately, enterprises all too often make the mistake of hiring a provider that specialises only in public cloud deployments, also called a “born in the cloud” provider. Because the enterprise has in-house expertise in on-premises or private cloud infrastructure, they are attracted to companies who promise exclusive expertise in the public cloud.
This type of MSP is usually best equipped to deal with new applications and greenfield deployments, and as a result will frequently stay far away from an enterprise’s legacy applications and traditional IT staff. They will often perform a cursory audit of the application, and may deploy the application in a public cloud without understanding the application’s weaknesses, which tiers/features cannot be replaced by cloud platform’s resources, and the roles of the engineers that maintain that application.
This is a crucial function for enterprises. Some enterprises supplement their managed cloud service provider with a consultant, but with hundreds or thousands of legacy applications, hiring consultants to perform this work on a near-constant basis is cost-prohibitive. Overall, trusting legacy applications to a cloud-only team may result in higher costs for hosting that is not even as secure or highly available as on-premises hosting, not through the fault of the cloud platform itself but due to mismanagement.
At a time when the vast majority of enterprises will implement a combination of on-premises, private, and public cloud environments, they need a partner that understands all three. They need an MSP who can deploy greenfield public cloud environments in a relatively short span of time, but also has experience in traditional enterprise hosting in order to understand legacy applications and communicate in the same language with their not-yet-cloud-ready internal teams. Enterprises no longer need to manage both traditional hosting partners and cloud partners, but can maintain a single MSP for both private and public deployments.
This allows enterprises to maintain a single relationship, a single contract, SOW and SLA, and a single “throat to choke”. This level of organisational simplicity makes it possible to move applications between public/private clouds with the same vendor. This dramatically reduces organisational friction by reusing a team that has already integrated with the internal team. As an added benefit, traditional IT staff and cloud engineering staff both connect with a single external team of DevOps experts, enabling the further spread of a single set of best practices throughout the organisation.
A cloud MSP with traditional IT knowledge can often communicate more effectively with your internal IT teams in “translating” cloud resources, which makes it possible for the MSP to integrate with, coach, and educate the internal team about cloud best practices. They will often recommend and document the enterprise’s deployment processes and use tools like Jenkins and Puppet to allow developers and cloud engineers to work together more seamlessly. In this way, they function as DevOps implementers and internal change-makers, not mere consultants who usually must be hired multiple times because internal divisions, heavyweight processes, and poor deployment strategies are gradually reinstated after they leave. Unlike consultants, managed service providers are incentivised to educate and change internal IT staff’s processes – because it makes their lives easier.
In addition, not every application tier is immediately suitable for the public cloud. There are many legacy systems – like Oracle RAC, for example – that have no replacement in a cloud platform like AWS. There may also be business reasons why it is not advisable to move all tiers of an application, such as when significant capital has been invested in custom database or virtualisation systems. An MSP that understands both traditional IT and cloud infrastructure will not only be able to better audit and advise enterprises on this score, but may even be able to transport that physical hardware to their own data centre so that the enterprise can get all the benefits of outsourced management while maintaining colocation between their database tier and other tiers hosted on the public cloud. The cost savings and agility benefits of such a configuration can be significant.
From a technical perspective, this scenario also enables enterprises to employ a single monitoring interface that spans both environments. Often third party security and monitoring tools like EM7 or Alert Logic are employed, each of which provide tools for both private and public cloud deployments. This monitoring interface is a crucial component of any true DevOps team, and often acts as a single source of truth when something does not go as planned. Dashboards help reduce finger-pointing when the “blame” is clear, and both the internal IT team and the MSP can focus instead on implementing a solution. This will also allow internal teams to see what is beneath the covers.
While it may be attractive in the short-term for large enterprises to hire cloud consultants or cloud-only MSPs, these are often stop-gap solutions. They fix current issues and support new lines of business, but require additional time and expense to manage legacy applications, educate internal IT teams, and monitor across both environment. Hybrid deployments require teams that understand where an enterprise is right now – on its way to a more agile, customer-driven model, but needing some help to get there.
The post Managing Hybrid Clouds: What Team Do IT Leaders Need? appeared first on Gathering Clouds.