devopsy.kinsta.cloud

Category: DevOps in the Cloud

  • SolarWinds Acquires Loggly to Add Analytics to DevOps Portfolio

    SolarWinds Acquires Loggly to Add Analytics to DevOps Portfolio

    An ongoing SolarWinds effort to drive down the cost of implementing DevOps has been extended by acquiring Loggly, a provider of log analytics software provided as a cloud service.

    Christoph Pfister, executive vice president of products at SolarWinds, says the Loggly service rounds out a portfolio of DevOps offerings spanning application and infrastructure monitoring, website monitoring and log management software.

    In keeping with the company’s overall DevOps strategy, SolarWinds will provide access to Loggly at substantially less cost than rival log analytics platforms such as Splunk, Pfister says. Pricing for the Loggly service starts at $99 per month. In contrast, other log analytics platforms charge IT organizations based on the amount of data being analyzed, which results in many of them limiting the amount of log data they analyze because of cost concerns.

    IT organizations have been making major investments in log analytics to more proactively discover anomalies indicative of either potential application performance issues or security breaches. The more log data being analyzed, the more accurate the analytics being applied to those logs becomes. The goal should be to make data science capabilities as broadly available as possible, says Pfister.

    Next up, Pfister says SolarWinds will be working on unifying the user interface experience between Loggly and the rest of its DevOps portfolio. In addition, SolarWinds is examining whatever opportunity there may be to bundle various cloud services together in a single suite of offerings, says Pfister.

    Log analytics has emerged as a foundational component of both DevOps and, by extension, digital business transformation. Developers are keenly interested in being alerted to events that might have a potential impact on their applications before they occur. IT operations teams, of course, are relying on analytics to enable them to be more proactive when it comes to making sure IT infrastructure resources are continuously available. At the same time, business users are discovering that log analytics can provide them insights into events that are indicative of how, for example, end users are employing new capabilities that have been added to a website.

    While most IT administrators have a lot of experience hunting through logs looking for specific events, the sheer volume of data in those logs prevents most of them from gleaning anything that approaches actionable intelligence. Advanced analytics applications provide the means through which all the log data being collected becomes more valuable to the business.

    As it becomes more affordable for more IT organizations to apply monitoring and log analytics, the number of IT organizations embracing DevOps practices should increase. Having access to tools, of course, is only one part of the equation. But most organizations wind up backing their way into DevOps, starting with tools that provide them additional capabilities and insights. Once they master those tools they begin to apply the knowledge and insights they gain to implement more sophisticated DevOps processes. For many IT organizations, however, the cost of acquiring those tools to get started down the path to DevOps has simply been too high.

    — Mike Vizard

  • Legacy On-Premises Apps Got You Down? Cloud DevOps to the Rescue!

    Legacy On-Premises Apps Got You Down? Cloud DevOps to the Rescue!

    With all the buzz around DevOps we tend to assume that everyone is doing it. But the reality is that most companies are not. That’s because organizations using legacy, on-premises applications think that it can’t work for them, and, according to IDC, the vast majority of enterprise apps still reside on-premises. Even in 2018, less than 28 percent of the worldwide enterprise applications market is expected to be software-as-a-service (SaaS)-based. But even if your organization is weighed down by legacy apps in your data center, that doesn’t mean you can’t do DevOps in the cloud.

    DevOps Requires Cattle

    A good reference point for DevOps is the “cattle versus pets” analogy. That is to say, you should treat your servers as cattle, not pets: They all should get fed and treated equally so that all your test labs will be the same. The problem is, when it comes to test labs for on-premises apps, it seems as though everyone has pets, while only the new breed of SaaS apps are treated like cattle. This is because the labs are very complex and have a way of accumulating their own unique settings, prompting conversations such as:

    “What is this 5000-line XML?!?”

    “Oh, that was configured by Adam in 1999 and we copy it verbatim ever since.”

    “Who’s Adam?”

    “Oh, he hasn’t worked here for five years.”

    Good DevOps practices require an organization to have multiple identical labs, available on-demand. You don’t get that with pet labs. Therein lies the problem.

    The Dreaded Configuration Drift

    Pet labs also lead to some other bad phenomena, such as configuration drift. Configuration drift results from the fact that it’s really hard to maintain even one lab correctly, so deploying and managing two or three or 20 labs becomes a daunting and very error-prone task. Since it’s easier, people often will simply copy images of other labs. But over time, those labs keep getting manually configured to account for various version needs and bug fixes. Hence, the “drift.”

    One cure for drift is starting from scratch every time. But for those “pet” labs (like the one Adam, who no longer works here, configured himself and was the last person alive who knew how and why), starting from scratch every time is intimidating and impractical, so they just keep drifting along. That means even though your test labs are supposed to be exact duplicates, they aren’t.

    ‘It Works for Me’  and ‘Cannot Reproduce’ Syndromes

    Inconsistencies between labs also lead to some common syndromes in bug tracking systems known as “works for me” and “cannot reproduce.”

    Here’s how these play out: The QA team has its own set of labs (hopefully they aren’t individual snowflakes), as does each dev team, and there are customer environments—another type of beast. Now all hell breaks loose—some bugs appear only in QA and not in the customer or dev environments, while others are only at the customer level. Miraculously, everything always works in the developer lab because those labs haven’t been reinstalled since the era of vacuum tubes and they contain every registry hack, debug symbol and kernel patch known to mankind.

    The “cannot reproduce” syndrome creates a lot of wasted time. When the QA person finds a bug, they talk to a developer, but developers are not in a bug-fixing sprint, and say they will get to it in a couple of weeks. So the labs move on. Meanwhile, two weeks later, a developer finally puts in a few hours but doesn’t find it and closes out the bug with “doesn’t reproduce.” Then the QA puts in another three hours trying to find it again.

    The Serious Issue of Lab Scarcity

    Last, but not least, physical in-house labs cause lab scarcity. Many companies find it too expensive and not cost-effective to build and maintain the number of labs they would need to enable all teams to work in parallel. With a limited number of labs, developers have to wait for others to finish their tasks before they can claim the lab for their own work. From my own experience, we had developers that wouldn’t leave the lab to take lunch breaks because they didn’t want to risk losing their place in the queue; they actually lost weight from not eating lunch all week (maybe a good thing for some?).

    Lab scarcity is literally a DevOps killer, not to mention the consequence of wasted developer time. (One can argue that wait time for lab spent on Reddit isn’t truly wasted, but that’s another story.) The point is, you want a lab for every developer, for every tester and for every CI run. Disney World-level wait lines are not a DevOps enabler.

    DevOps in the Cloud

    The ultimate goal is to create identical, reproducible test environments for every test, tester and run that are elastic, burstable and present short feedback loop times. This is what brings you to cloud.

    Using the cloud to replicate and share identical labs that can easily be started over and saved at a specific state is the way to avoid these problems. But not all public cloud providers are created equal, especially when it comes to re-creating complex, on-premises environments in the cloud.

    Commodity cloud providers AWS, Google and Azure present one option. However, they have little to no support for uploading your images, no complex L2/L3 networking support, little to no nested virtualization and no promiscuous mode adapter. After all, they are built for “cloud-native” apps.

    Another option is to build your own data center. But this is costly in terms of hardware (which repeats every two to four years) and fairly complicated to do properly, and involves lots of overhead for creating and maintaining them. Eventually, you’ll probably realize you’re not an infrastructure-as-a-service (IaaS) company and that you prefer to focus on your core business.

    The best option is to look for something as convenient and agile as commodity cloud, but which is specialized for your on-premises challenges.

    For many cases, you’ll find that specialized virtual IT lab providers let you replicate production server images in the cloud without modification, and also save templates of production labs regardless of complexity or number of nodes. These providers should enable you to quickly spin up as many identical environments as needed and then easily connect tools and scripts to automate processes across systems.

    When it comes to debugging, make sure you can easily capture snapshots of issues to get back to the same spot later. Then look for automation capabilities that save time and control costs, such as environment policies, auto-suspend, Zapier integration, organizational structure modelling and more.

    A Sample Use Case

    Smaller startups often run into challenges because they want to run fast with very big systems. Take, for example, the case of a financial trading company that started out by investing in production instances and tweaking them manually. The system comprised more than a half-dozen subsystems, each with its own programming languages, technology stacks and deployment methodologies. Developers working on one subsystem had virtually no knowledge about the others, except for how the interfaces behaved. The setup worked in production (most of the time …), but then quality issues mounted.

    The company first invested in a waterfall-like methodology with long QA cycles. But much of the QA happened in production because there was no complete staging system. And when you are a financial trading organization dealing with people’s money, doing QA on your production environment becomes costly in multiple ways.

    The lack of a safety net in the form of a complete staging environment also slowed the deployment of new features. Even if a change was working nicely internally within the subsystem where it was made, it still would have to be orchestrated with the larger system—sort of like a composer who changes a note for one instrument then has to call all the players to hear it with the entire symphony.

    The company eventually solved its issues by uploading complete images of its existing production machines to the cloud, then divided them into subsystems with different blueprints. Once the company established a “golden blueprint” of each subsystem, it became very easy to test by mixing and matching servers from different blueprints. To continue the composer analogy, the company could now change the notes in one subsystem and see how it sounds together by playing them together with recordings of all the other players.

    The company ended up achieving a dramatic decline in the number of production issues, and significantly increased the speed at which it could develop new features (no doubt one runs faster on the high wire when a safety net exists).

    Special Bonus for Docker Users

    Snapshots also come in particularly handy when using Docker. In a Docker-based environment, current practice is to run CI tests on the actual Jenkins slaves in an ephemeral way, which disappears between consecutive runs. This means you only have logs of the end results. But what happens when there is a failure and you want to debug? The bug may appear to be non-deterministic when it is actually deterministic because something has changed between tests. And even if the bug is deterministic, you still have to re-create it. Imagine if instead of running tests on ephemeral Jenkins slaves, you spin up an ephemeral cloud-based Docker machine and, in case of test failure, you set your CI to take a snapshot. You can then go back to your snapshot later and employ traditional debugging techniques, saving precious developer time.

    DevOps for All

    Doing DevOps in the cloud can make all of this possible. No matter how old and complicated your architecture may have become, you can still get into the game. Just remember that cattle are easier to herd than cats.

    — Muly Gottlieb

  • HPE Rises to Multi-Cloud Management Challenge

    HPE Rises to Multi-Cloud Management Challenge

    Hewlett-Packard Enterprise (HPE) is making available a suite of tools to unify the management of public and private clouds via a software-as-service (SaaS) applications.

    Bryan Jacquot, HPE worldwide user experience architect, says HPE OneSphere provides IT organizations with a means to manage a multi-cloud IT environment using a SaaS application they can consume in the same on-demand manner they employ to deploy cloud applications on-premises or on a public cloud service.

    HPE OneSphere makes uses of application programming interfaces (APIs) to unify the management of diverse IT environments under a common software-defined framework.

    Within that management application, HPE has also provided Project workspaces for different types of individuals and teams, including IT operations, business users, developers and data scientists.

    Jacquot says HPE makes use of Docker and Kubernetes container technologies to provide the foundation for HPE OneSphere. The goal is to make it easier for IT organizations to manage any combination of hybrid cloud computing environment they choose to craft.

    To one degree or another, most IT environments today are multi-cloud. They typically employ at least one public cloud alongside an on-premises IT environment that is becoming more cloud-like. At the same time, many IT organizations either already have or are planning to add an additional public cloud service, if for no other reason than to play Amazon Web Services (AWS) against Microsoft Azure. However, each stack of public and private cloud computing requires them to master a separate management plane, which drives up the total cost of ownership (TCO) of an IT environment—which creates a challenge at a time when many IT organizations are looking for both lower costs and increased agility. Through OneSphere, however, HPE is resolving that issue by providing access to one common management portal for both on-premises IT environment and public cloud services, says Jacquot.

    There are other means to develop a common management plane spanning multiple clouds. But building, deploying and maintaining a management framework spanning multiple clouds can be a complicated endeavor. HPE OneSphere presents IT organizations with a portal through which all the underlying APIs are abstracted away from the IT operations team, making the process simpler, says Jacquot.

    It’s unclear at what rate IT organizations will move to unify the management of multiple clouds in 2018. Different parts of an organization often fund adoption of different classes of public cloud services. At the some point internal IT teams are tasked with managing those services. But the constitutional crises that drive those events might not occur until 2019 or beyond within many organizations.

    Regardless of the approach taken to managing multiple clouds, there’s no doubt that the distribution of application workloads across multiple internal and external platforms represents arguably the biggest DevOps challenge of 2018. Organizations that get in front of this issue today are likely to find managing IT to be much easier in the years ahead. Those that don’t are likely to experience more pain than they might have ever bargained.

    — Mike Vizard

  • Persistent Storage: You’ll be Hearing More

    Persistent Storage: You’ll be Hearing More

    As containers take over the IT environment, a problem that has existed since virtual machines (VMs) became popular has become more urgent: how to keep persistent storage, and keep it consistent.

    Just as a business designed for foot traffic of 50 to 100 people per hour does not work well when it sees 500 to 1,000 people per hour (think Black Friday in most places these days), storage designed to hold data that persists across instances and even installations often struggles in containerized environments.

    There are a couple of reasons why this is so.

    First, we now treat our servers as disposable resources. If one dies, we leave it dead and simply spin up another. Normal processing keeps the dead server for later evaluation, but many shops do not follow this best practice. The issue has to do with servers that die when writing to persistent storage—what was the state of the write? Did it get interrupted mid-transfer? Luckily, applications can be designed to account for this, and the increasing prevalence of transactional processing in applications that are not based on a database management system (DBMS) shows that people are doing just that.

    Second, the number of server instances hitting those persistent stores is higher in a containerized environment—they are smaller, lighter and faster to spin up and their container density is generally higher than VM density. Contention issues go from zero to full-on when an app goes from “one server is writing to this persistent store” to “two servers are writing to this persistent store.” And often there are hundreds of servers writing to the persistent store. As mentioned, the stop-gap is to implement some form of transactional processing to prevent writes and overwrites.

    Persistent Storage: It’s Got Issues

    The problem is, we end up with transactional processing written into dozens or hundreds of server instances to protect a small number of persistent disks. This is not optimal, and at a minimum increases software complexity.

    That’s why you’ll be hearing more. Here are a few places working on simplified but powerful persistence ideas:

    {code} Rex Ray

    Originally part of EMC, {code} is Dell’s open source group and it has led the charge on the container storage interface (CSI) that facilitates persistent storage. Examples the company has implemented include databases and Minecraft, but the technology works for anything that must be stored on disk.

    Container Orchestration Engines and Cloud Providers

    All of the well-known container orchestration engines (COE) and infrastructure-as-a-service (IaaS) cloud vendors have methods to handle persistent disk—some more transactional than others and some more work than others. Expect this process to become standardized (and possibly for that standardization to take the form of CSI above) in the next year or so. If persistent data is critical to your container environment, it is worth looking at how each solves the problem, as some of the solutions are procedural (such as Docker’s recommendation), and thus are somewhat portable across COE solutions. The weakness of IaaS providers is portability between systems, but that is true of all IaaS procedures/solutions at this time.

    Virtualization Engines

    Both VMware vSAN and Microsoft NTFS have systems for providing persistent disk. While much of this is the simple case of “disk that doesn’t disappear when the container does,” that is the bulk of persistence needs. Expect the support to continue to expand, perhaps even going so far as to implement 100 percent transactional shares.

    Storage Array Vendors

    Storage array vendors have useful tools for this area. While what you use to access their storage is not too terribly large a concern to these vendors, they do have a vested interest in seeing that their storage meets the needs of the changing enterprise. As such, they are delving into methods to help make persistent storage available and consistent. This is not a huge stretch for the vendors, as the systems they produced were always intended for multiple access. Where they lag (and where Rex Ray steps up) is in interoperability/interchangeability of vendor solutions.

    Conclusion

    For those with controlled access to persistent/shared storage, these issues are not that big a deal. For high-volume or high-turnover DevOps installations, though, persistent storage is another link in the chain of reliability that must be protected. Keep kicking it, and hopefully before your need becomes urgent, a solid system will be in place to manage and protect persistent stores.

    — Don Macvittie

  • ZeroStack Advances Self-Service Provisioning on Private Cloud

    ZeroStack Advances Self-Service Provisioning on Private Cloud

    Many IT organizations have aspired to build a private cloud only to find that they don’t have the granular control over IT infrastructure to deliver on that promise. To solve that problem, ZeroStack unveiled DevOps Workbench, a framework internal IT organizations can employ to present developers with a set of options that can self-select to automate the deployment of an application in an on-premises environment.

    DevOps Workbench is designed to layer on top of the ZeroStack Intelligent Cloud Platform, which combines 40 developer tools and templates on top of a layer of abstraction based on a Kernel-based virtual machine (KVM) to unify the management of underlying IT infrastructure via a cloud management service. Steve Garrison, vice president of marketing for ZeroStack, says DevOps Workbench adds a self-service framework on top of that private cloud to present developers with an experience similar to the way they provision resources on a public cloud. The company also announced it has added DeployHub, continuous deployment software from OpenMake, to the portfolio of DevOps tools it makes available.

    Garrison says developers have been doing an end run around internal IT organizations for years now because it takes too long for internal IT teams to make infrastructure resources available. ZeroStack aims to solve that problem by first applying an abstraction layer to create the private cloud, which is then managed via a suite of software-as-a-service (SaaS) applications that ZeroStack exposes in the cloud.

    Rather than trying to force collaboration between developers and internal IT teams, Garrison says DevOps Workbench allows both groups to accomplish what they need without getting in each other’s way. Developers can access a user interface to provision IT infrastructure within a set of use cases predefined by the internal IT team.

    Because of performance issues and compliance concerns, there are whole hosts of applications that will not be deployed in a public cloud. But the IT teams who manage those applications are still under pressure to provide developers with a cloud-like experience. In fact, Garrison notes that in 2017 research by Gartner found that 76 percent of respondents indicated that they are using DevOps in regulated situations, an increase from 47 percent in 2015.

    ZeroStack rivals also are advocating transitions to software-defined data centers (SDDC). But most of those efforts involve expensive upgrades to both software running on virtual machines and the underlying infrastructure. Garrision says a private cloud approach that relies on cloud management services provides a faster, less costly, means to achieving the same goal, especially in midmarket IT organizations that don’t have access to much internal expertise to begin with. He adds that ZeroStack is committed to providing support for additional hypervisors soon.

    Most IT organizations are still a long way from being able to build, deploy and manage a true private cloud at scale. Most of them have what might be more aptly described as large virtual machine farms. The operating costs associated with managing virtual machine farms will eventually push most IT organizations to some form of an SDDC platform. It’s just not clear yet what the preferred path for making that journey will be.

    — Mike Vizard

  • VMware Adds vRealize Automation to Cloud Platform

    VMware Adds vRealize Automation to Cloud Platform

    At the core of the VMware approach to cloud computing is a VMware Cloud Foundation platform that combines storage and network virtualization software with the company’s core hypervisor platform. Now via the release of VMware Cloud Foundation 2.3, integration with the VMware vRealize portfolio of IT automation software is being added.

    Matt Herreras, director of product marketing for VMware, says the inclusion of VMware vRealize Automation, vRealize Operations and vRealize Log Insight will make it easier to deploy application workloads on a platform that VMware manages on behalf of customers, whether it’s deployed on-premises or in a public cloud.

    IT organizations will also be able to use the management console VMware provides with VMware Cloud Foundation to configure the vRealize automation framework.

    At the same time, VMware is adding support for heterogeneous servers within a single rack, including be able to specify specific servers for each workload domain.

    Additionally, VMware has revealed it is working with Intel to include the latest family of Intel Xeon Scalable processors in an existing Intel Select Solutions for VMware Cloud Foundation program. Those processors are expected to be certified in the first half of 2018.

    VMware Cloud Foundation is rapidly becoming a centerpiece of the VMware approach to DevOps. VMware claims that a VMware-based cloud can be spun up six to eight times faster using VMware Cloud Foundation, while total cost of ownership of a private cloud will drop 30 percent to 40 percent and administrator productivity will increase by a factor of two.

    IT organizations that have standardized on VMware are under significant pressure from developers to become more agile. In many cases, those developers end-run the internal IT organization by programmatically invoking cloud services, even if it would be more cost-effective for the application workloads to deploy locally. The challenge those administrators and VMware both face is convincing developers that VMware environments are flexible enough to meet their need to access IT infrastructure on demand, now that an IT automation framework has been tightly coupled with VMware Cloud Foundation.

    In the meantime, VMware is also betting that as large numbers of existing applications are lifted and shifted into the cloud, most IT organizations would prefer to not have to refactor them. To allow IT organizations to avoid that issue, VMware is making VMware Cloud Foundation available jointly with Amazon Web Services (AWS), while partners including IBM provide their own managed instance of VMware Cloud Foundation. Herreras notes that the VMware vRealize automation suite also includes tools for managing AWS and Microsoft Azure environments as an extension of a local VMware environment.

    In addition, VMware has invested in container technologies including Docker containers and Kubernetes clusters, which can be deployed on VMware. Herreras says that from an IT operations perspective, the company is betting that most IT organizations will prefer to deploy legacy monolithic applications and emerging microservices applications on top of a common base infrastructure to minimize costs.

    It might be a little while longer before VMware can completely pull all the elements of its DevOps strategy together. But the one thing that is clear is that, at the very least now, the company understands just how much of its continued future relevance in enterprise IT is at stake.

    — Mike Vizard

  • Cloud Orchestrators: Beneficial in a Multi-Cloud Environment

    Cloud Orchestrators: Beneficial in a Multi-Cloud Environment

    Recent outages of leading cloud providers affecting thousands of business worldwide, such as the Amazon Web Services S3 outage that occurred in late February, have forced many CIOs and CTOs to think hard about their cloud strategies, including whether a multi-cloud environment would be of benefit.

    ROI and Business Impact

    During AWS’ four-hour disruption, S&P 500 companies lost $150 million to $160 million, according to analysis by Cyence, a startup that models the economic impact of cyber risk.

    Web monitoring company Apica, which watches internet performance issues worldwide, discovered that 54 out of the top 100 internet retailers were impacted with a decrease of 20 percent or greater in performance, and three websites went down completely—Express, Lululemon and One Kings Lane—resulting in a high impact in business.

    During this outage, according to Apica spokesperson, Apple and other ecommerce sites were likely spared for an easy reason: They have designed their sites to spread themselves across multiple cloud vendors, so if a problem crops up in one cloud service, it doesn’t hurt them. This is, naturally, the recommended way to use a cloud service.

    Apple, Walmart, Newegg, Best Buy, Costco and, surprisingly, Amazon/Zappos were not affected by the outage.

    Organizations have since started looking for different means to avoid data loss and downtime and to better support different applications, not to mention resilient application support, customer management and data analytics. This is where multi-cloud computing can help solve the challenges and which focuses provisioning, managing and monitoring workload across many clouds.

    Multi-Cloud Computing

    Multi-cloud computing is termed as the use of more than one cloud environment, all of the same type or a mix of types, to satisfy business requirements. An enterprise can choose which workloads can be moved to different clouds, depending upon the service offered by cloud vendors, matching the business need.

    This article discusses the need of multi cloud adoption, its benefits and challenges in managing multiple cloud environments and how multi-cloud orchestrators help solve the challenges.

    Market Trend

    According to research firm IDC, by 2020 more than 85 percent of enterprises will adapt to multi-cloud architectures encompassing a mix of public cloud services, private clouds, community clouds and hosted clouds, driving up the rate and pace of change in IT organizations.

    According to research firm MarketsandMarkets:

    Cloud Model 2016 2021
    The Multicloud management market $939.3 million $3.4 billion (compound annual growth rate of 29.6%,)
    The hybrid cloud market $25.28 billion $84.67 billion

     

    What is Driving Multi-Cloud Adoption?

    All workload and business requirement cannot be the same—this is one of the primary drivers of a multi-cloud reality.

    Unique Needs: You can run each workload where it performs best, for the lowest cost.

    Legacy Apps: You can avoid the pain of migrating legacy apps to a new platform.

    Desire to Diversify: You can avoid vendor lock-in and latency while creating redundancy.

    Benefits of Multi-Cloud Computing

    • Flexibility: Companies can deploy to public, private and hybrid clouds using a range of services.
    • Reduce the expenditure: Competitive prices and services from different cloud providers enable companies to achieve optimum cost expenditure.
    • Enhanced autonomy: Companies avoid keeping all their IT workloads in one cloud provider’s basket.
    • Customization and enhanced IT performance: Customization leverages the best-of-breed capabilities from multiple cloud vendors.
    • Migration: Containers and microservices-based applications can be migrated easily across clouds.
    • Hardware diversity: Relying on multiple locations and multiple providers significantly reduces the chances of impacting QoS.
    • Avoid data loss and downtime: Using more than one cloud services helps an organization avoid data loss and downtime attributed to a breakdown in any single component in hardware, software, storage or network.
    • Multiple Geo Availability: Companies can leverage cloud vendors’ data centers in multiple geographies, enabling to scale the business.

    Challenges of Managing Multi-Cloud Environment

    While there’s a lot of talk about moving things between clouds, the reality is it’s still fairly new. Though clouds have become smart enough to put an end to data lock-in, every vendor deployment comes with its own set of challenges, such as unique portals and processes that companies need to manage and can be put into three different categories.

    Technical challenges

    • API: No single model of integration or infrastructure automation can work, as each cloud provider will provide a different API to access different cloud services.
    • Behaviors: There are many differences in how clouds behave for common actions or under certain circumstances. For example, some clouds automatically provision storage upon launch of a server or instance, while others do not.
    • Resource sizes and types: Each cloud provider will offer different sizes and types of compute, storage and network resources; hence, the IT team must think about provisioning with optimum resource size and type needed for their workloads.
    • Operating system images: Each cloud provider will provide a unique set of operating system images, which makes it difficult to run the workload using the same image in other cloud.
    • Hypervisors: Each cloud provider leverages different, and sometimes proprietary, hypervisor options.
    • Application stacks: Some cloud providers may provide a selection of common, preconfigured application stacks (such as LAMP or Java or .NET).
    • Add-on services and features: Each cloud provider will offer extra add-on services and features above and beyond basic compute, network and storage resources. These may include load balancing, application servers, analysis tools or databases.
    • Security capabilities: The access control capabilities will vary across cloud providers, becoming more complex if different providers demand different password complexities or authentication measures.
    • Network Capabilities: Each cloud offers different ways to define subnets, security groups and network gateways, increasing difficulty in network planning.

    Operational Challenges

    • Testing: Deploying apps to multiple clouds requires platform-specific testing, which needs separate automate tests targeting multiple cloud platforms.
    • Tool diversity: DevOps tools have to keep pace with the rapid changes being made to the platforms.
    • Maintaining security and governance: Companies will need to go through rules and regulations of each service provider to adhere to security compliance.
    • Managing applications and infrastructure configurations across multiple cloud stacks: This can be difficult since the cloud platforms do not share a common API, which exposes different service definitions and billing models.
    • Technical support and expertise: Extra administrative work and research is required to to determine the best provider and whether its services are compatible.
    • Geo-availability: Expand the business into new markets can be a challenge, as not all cloud providers have global footprints and offer data centers only in limited locations.

    Business Challenges

    • Cloud brokers: Managing cloud brokers is an additional cost while using multiple clouds.
    • Billing and Pricing: Each cloud provider offers unique pricing models as well as different billing capabilities, which necessitates the need for governance and cost optimization, providing summary along with detailed cost tracking across clouds.
    • Skill sets and training: A lack of skill set and expertise in different clouds in the organization can lead to outages of workloads and increase cost/effort.
    • Planning and execution: It can be difficult to choose the services that match a company’s business needs, pricing, governance and team’s expertise.

    How a Multi-Cloud Orchestrator Helps

    Regardless of the challenges, multi-cloud environments are growing, thanks in part to multi-cloud orchestration tools, which can prove to be a right fit to address above discussed challenges.

    These orchestration tools have the capability to make multiple cloud providers look like a single provider ensuring configuration of all cloud dependencies within one configuration model. These tools enable companies to automatically deploy and manage multi-cloud environments.

    Some of the big players in this segment are RightScale, OneOps, Cloudify and IBM Cloud orchestrator, which provide a standard set of interfaces and capabilities across a multi-cloud environment.

    We have identified some parameters which current multi-cloud management platforms are well-equipped to handle:

    • Planning and Execution of an application from design to transition to deployment.
    • Installation & configuration of infrastructure packages & services in an automated way.
    • Provisioning of application environment.
    • Deployment plan and execution.
    • Cost Management: Suggestion of cost effective cloud services and single dashboard to track the cost associated with different cloud services.
    • Monitoring of entire application stack.
    • Security & Governance as to who can view, create, execute environment related activities.
    • Blue-print Templates which can be easily reused to create a new environment.
    • Reporting: View a report of instances that are consumed by your organization across multiple clouds.

    Conclusion

    Multi-cloud orchestrator tools help address some of the above  challenges to configure, provision and deploy several cloud environments, as well as integrate service management from a single, self-service interface.

    Though present multi-cloud orchestration tools offer a more time- and cost-effective solution to manage different cloud providers for organizations to focus on larger business objectives, virtually all products in this category are young—bugs and inconsistencies can and will occur. Additionally, security can be a concern for many of the popular orchestration tools. Many APIs offered are not securely encrypted by default and need to have SSL added separately.

    We can say there is still a huge scope of improvement for multi-cloud orchestration tools to build more secure, easy-to-set up standardized workflows across different cloud providers to cover the challenges which multi-cloud computing era offers.

    About the Author / Rashi Sharma

    Rashi Sharma an architect working with Technology Office in HCL Technologies. She has expertise in AWS, DevOps consulting & configuration management methodologies. She is associated with DevOps COE, working on design and Development of DevOps solutions.

  • Morpheus Data Advances DevOps Across Hybrid Clouds

    Morpheus Data Advances DevOps Across Hybrid Clouds

    Thanks to the rise of multi-cloud computing, the challenges associated with managing DevOps are becoming exponentially greater. Most IT organizations are not likely to be 100 percent sure at any given time which application workload is running where.

    To address that issue, Morpheus Data has added a Cross-Platform Discovery module to its Unified Ops Orchestration platform that employs machine learning algorithms to determine not only what applications, virtual machines and containers have been deployed on-premises or in a public cloud, but also how much capacity, memory usage and power consumption each is using and their and overall performance.

    At the same time, Morpheus Data is adding integration with Github and Jenkins continuous integration/continuous delivery (CI/CD) environments as well as support for both Docker Swarm and Kubernetes clusters.

    Finally, Morpheus Data has added connectors to IBM Cloud, Upcloud and HPE OneView services and been certified as a ServiceNow partner. The Unified Ops Orchestration platform already supports Amazon Web Services (AWS), Microsoft Azure and Google Cloud Platform.

    Brad Parks, vice president of marketing and business development for Morpheus Data, notes that as IT environments become more distributed in the age of the cloud, new approaches to change management will be required. The Unified Ops Platform provides an opportunity to consolidate change management processes within the context of a single control plane.

    While more IT organizations are making use of multiple cloud services, most are managing each IT environment in isolation. Over time, the lack of unification of the control planes for each of those environments conspires to increase the total cost of ownership for IT. Morpheus Data is making a case of for unifying the management of multiple platforms running on-premises or in public cloud instead of requiring IT staff to master multiple management tools.

    That single management plane, Parks says, also makes it much easier for IT organizations to take dynamically employ multiple cloud environments. Price points for cloud services are liable to change at any moment, but it doesn’t necessarily follow that the same type of workload will continue to be deployed on the same cloud. At the same time, the characteristics of a workload may have evolved to the point where it doesn’t make financial sense to deploy it on a public cloud. A common management platform makes it possible to move that workload with the least amount of disruption possible.

    Most IT organizations today are concerned about getting locked into a cloud service provider. Being able to demonstrate an ability to switch between cloud service providers gives IT organizations an opportunity to negotiate cloud service contracts from a position of strength. Most cloud service providers are counting on the fact that the cost of switching from one provider to another is simply too high. Integrated DevOps processes wrapped around a common management plane, however, will make it clear to all concerned that the platform provider serves at the pleasure of the internal IT department, not the other way around.

    — Mike Vizard

  • DevOps Chat: ParkMyCloud Saves Wolfpack App Over 50 Percent on Cloud

    DevOps Chat: ParkMyCloud Saves Wolfpack App Over 50 Percent on Cloud

    In this DevOps Chat, find out how the developers of Wolfpack (wolfpack.run) are saving over 50 percent in cloud costs by using ParkMyCloud’s cloud management platform.

    Though the cloud offers many benefits to app developers and others, controlling the costs can sometimes elude organizations big and small. Cloud sprawl can quickly lead to large cloud bills. In this chat, we speak with Jonathan Chashper, CEO of Wolfpack, about how his company got a handle on the cloud and is spending less than 50 percent of what it was paying before.

    As usual, the streaming audio of our conversation is below, followed by the transcript of our conversation.

    Audio

    Transcript

    [su_pullquote align=”right”] [su_custom_gallery source=”media: 118815″ target=”blank” width=”200″ height=”200″]Chris Parlette
    Chris Parlette is the Director of Cloud Solutions at ParkMyCloud. Chris helps customers reduce their cloud waste and manage their hybrid infrastructures by drawing on his years of experience working at various software startups. From SaaS to on-prem, virtualization to cloud, monitoring tools to cloud management platforms, and small businesses to large enterprises, Chris has seen it all and loves helping drive improvements to IT management.[/su_pullquote]

    Alan Shimel: Hey, everyone, it’s Alan Shimel of devopsy.kinsta.cloud, and we’re here for another DevOps Chat. Today’s chat is actually a great behind-the-scenes look at ParkMyCloud and how an app provider named WolfPack is using Park My Cloud to really kinda get a handle on their cloud costs, their cloud usage and optimizing the cloud for their applications.

    That being said, let me introduce you to our guest for today’s podcast. Our first guest is the CEO and founder of WolfPack, and his name is Jonathan Chashper. Jonathan, welcome to DevOps Chat.

    Jonathan Chashper: Thank you, Alan. Thank you for having me.

    Shimel: Thank you. And then our second guest is from ParkMyCloud, it’s Chris Parlette, and Chris, I hope I don’t mess up the title, but it’s director of Cloud Solutions?

    Chris Parlette: Correct, yes. And thanks, Alan, for having us—appreciate being here.

    Shimel: Not a problem. So, guys, this is gonna be a fun one, I think. Jonathan, why don’t you give our audience a little background—what exactly is this WolfPack app?

    Chashper: Sure. So, WolfPack, we are—you can look at us as a connected vehicle technology focusing specifically on helping individuals move together. Think about how much fun it is to move as a group. Imagine you are, you know, maybe several families moving in a few cars. It’s a lot of fun, but there are two major problems—one, keeping everybody together, making sure people don’t get separated, don’t get lost. And the second one is actually communicating with each other while traveling and doing it safely.

    Now imagine you are now doing it on model cycles, which is the first niche we’re focusing on. So, we’re solving those two problems with WolfPack, and by the way, people can take a look at WolfPack.run-R-U-N-to see how it works. But generally, what we do is, we provide, with a turn-by-turn navigation, to every one of the people driving or riding, while providing a radar showing the location of everybody else.

    So, we actually make sure that everybody gets there without being killed, without being lost, without getting into a ditch, and making the experience much less stressful, and much more fun.

    Shimel: And that’s a good thing. But Jonathan, well, you know, WolfPack represents sort of this new—it’s not really new. I’ve seen them now for a couple years, but I call them these instant group type of applications where you can create a group on the fly and that group can have two people or 200 people or more, right? And this group then does something. In the case of WolfPack, you know, they’re on a run or a trip of some sort, and you have Google Maps built into it or underlying it and, you know, all of these things, and they’re great.

    The problem is, as you probably are well aware, is you never know from moment to moment, you know, what your load is gonna be, right? How many groups, how big a group, you know, what’s going on?

    And so, in resource planning, that can be a problem. Talk to me—

    Chashper: Correct.

    Shimel: —yep. Talk to us a little bit about what you’re doing with ParkMyCloud and how that’s helping you.

    Chashper: Mm-hmm. Yeah, so you’re absolutely correct. What you said at the beginning, it’s true. We can—our users can immediately generate groups, it can be, they can generate any number of groups. It can generate—any group can have any number of people. They can plan a ride which can be as short as 10 miles or as long as 1,000 miles, so you’re absolutely right.

    And so, when we’re building the system, obviously, it’s a cloud based system. We are on top of AWS. What’s important for us is that the development costs, being a startup, is being-you know, kept to the minimum. And so, what we did, we actually looked into ParkMyCloud, and with ParkMyCloud, we got to the point that we control our development costs very, very tightly. Generally speaking, when you’re using a server in the cloud, as long as you don’t turn it off, it still works and you’re still being billed for it. And if your development teams go home-say, they work 9 to 7 every day, they go home at 7. If the servers are off, you’re still paying for them.

    So, what we did with ParkMyCloud, we actually manage the up time of those servers, so we only pay for the time we’re actually using those servers for our development for our staging.

    The other good thing we’re having is that we actually have quite good visibility. True—a nice supporting feature, which I think is pretty new, where we can see very, very quickly, you know, when is our load high, what is actually being used, what is not being used, if anything needs to shut down. So, we can manage that very, very easily. And specifically, on the park management, it’s almost a file and forget. Once you set it up once, you never need to go back to it, and it just does it for you.

    Shimel: Got it. So, Jonathan, let me just be clear, I want to make sure we’re talking apples to apples. So, when you say, you know, you’re not using the server overnight or something like that, are you saying that, with ParkMyCloud, you can schedule your instances to close? So, in other words, I’m only gonna use this instance from 9 to 5, and at 5:00, retire that instance, close it out, don’t keep it on my billing account, and when I start up again tomorrow at 9, I’ll start a new instance with that same configuration and kind of pick up where I left off, or is it something else?

    Chashper: So, first, we need to understand that you can use ParkMyCloud on your non-production instances. Production instances obviously need to be up 24/7, so you don’t want to shut them down.

    Shimel: Yeah, you’re right—I should have said that. [Laughter] No one wants to shut down their production.

    Chashper: Yes. So, what I was referring to, I was talking about our development and staging nonproduction systems.

    Shimel: Mm-hmm.

    Chashper: Yeah, so that’s for that.

    Shimel: But are you actually—I guess what I’m asking, are you retiring those instances and firing up new ones the next day, or is it—

    Chashper: Oh, this is—yeah, so this is done automatically for us. That’s the beautiful thing about ParkMyCloud. We actually, once you set up the parking schedule, it will shut down the server, say, 5 p.m. today, and it will turn it on back tomorrow morning, say, 9 a.m. We don’t need to do anything. This is done for us automatically, and so you know, where the developers come back into the office, as far as they’re concerned, nothing changed, they just keep working.

    Shimel: That’s fantastic. Chris, I just want to confirm with you—those instances are actually, you know, it’s sort of like immutable infrastructure, right? Those instances are retired, done, and then re-fired up the next day?

    Parlette: Yeah, so what this is—and it’s not terminating the instances, it’s actually just stopping them and then turning the same ones back on. And the nice thing is about that, is that now, you know, as people are working on these servers, you know, if you haven’t fully gone with data, you know, not being stored on those servers, you know, as you’re working on these same servers over and over and over again, you know, we stop them and then start them right back up again. So, even if people like your finance department or your QA department maybe have some things, you know, spun up, we can actually turn them off to save on the CPU and memory costs, and then we just turn them back on again.

    Shimel: I got it. Okay, because I was gonna say, you know, I mean, the immutable infrastructure angle is great, but in this sort of circumstance, it’s not just a configuration of the server, it was the state of the data that you were working on, and how the heck would you re-create that every morning? [Laughter] But that explains it—got it.

    So, Jonathan, you know, so ParkMyCloud is making you guys a lot more efficient here in the cloud and your use of cloud resources. Have you been able to quantify a percentage savings or anything like that?

    Chashper: Oh, absolutely—most definitely. If I want to be, you know, conservative, I would probably say that we’re saving around 55 [percent]to 60 percent.

    Shimel: Really?

    Chashper: At least. Frankly, I think we probably save close to 70 percent. We’re really very tight. We really manage to do that in a very tight manner.

    Shimel: So, beyond just closing down and firing up the instances the next day, what are some of the other things you’re doing with ParkMyCloud?

    Chashper: Oh, so—well, for us, the first thing is reporting and notification. If something happens, we get notified, we can actually control what we get to be notified about. So, then we’ll get notification about maybe a server that needs to be shut down or something like that.

    Reporting is very important to us so you can see your usage, you can see what is up and what is down.

    Shimel: Got it.

    Chashper: One of the cool things we just started using is actually a mobile app. So, there is a mobile app on iOS for ParkMyCloud. People can download it at the iOS store. And it actually happened with me, I was at dinner, and we—my guys had to stay a little later, and we had to, what we call, snooze one of the parking, you know, schedules, and I just did that through the mobile app, I didn’t even have to go online.

    Shimel: Fantastic. Very cool. So, guys—look, 50 percent or better savings, all these other benefits is certainly nothing to sneeze at. I think anyone would jump at it.

    But, Chris, let’s dive in with you now a little bit, if we can. You know, we have an audience here of DevOps sort of folks from all over the world, right, who would love to save 50 percent on their cloud bill. How is ParkMyCloud working with these DevOps engineers and DevOps teams to realize those kinds of savings and efficiencies.

    Parlette: Sure, yeah. So, we work, you know, plug into a lot of DevOps processes and toolkits straightaway. I mean, that’s something that we do internally, and then, you know, we certainly have all of our customers, from large enterprises down to small startups, all doing this same kind of thing.

    And so, there’s a few different ways to do that. One of the big things about DevOps is automation, and so, we have a full policy engine so you can set up the policies to look at tags, to look at locations to different regions that these servers were in, naming schemes—all these different kind of factors, and you can automatically apply schedules and assign to teams and decide on different actions to take based on these policies for any new instances that you spun up. So, that’s one automated way.

    We also have a full API, so you could plug into DevOps tools like Atlassian, Bamboo or Jenkins so that these tools can kind of reach into our API, temporarily override schedules, change schedules—all this as a part of an automated thing.

    One of the other things about, you know, DevOps—not just automation, but also just thinking whole business, kind of a holistic approach to this thing—and so, we also have a full, a very easy to use UI. So, if your users are, maybe are a little less technical or you don’t want them to necessarily have direct access to a database console or Azure or Google consoles, this can kind of be sort of a proxy for that console so that other users can come in and manage their end servers. They don’t have to ask IT to turn things on for them. They can kinda manage their own servers and do all this, but you can decide who has access to what through this approach.

    So, there’s a couple different ways we plug into these teams and these processes so that users can get their best bang for their buck.

    Shimel: Got it, got it, got it. Now, so, Chris, when you talk about plugging into things like Bamboo or Jenkins, what you’re really—I mean, I just wanna make sure I’m clear. You can build sort of the ParkMyCloud—not sort of, but you can build the ParkMyCloud policies right into your CI/CD pipeline. Is that what you’re saying?

    Parlette: Yes, so if you do things like using tags, especially as instances are spun up or spun down, a lot of people say, you know, “Hey, I put a million tags on every instance.” And so, that’s what the ParkMyCloud policies can read off those tags and kinda decide on the actions based on those tags.

    And then, as far as things like—you know, specifically, if we were to talk about Jenkins or some other build processes, you know, you can have these environments built out and shut down. And then Jenkins, at the beginning of some sort of build process, can call into ParkMyCloud and say, “Hey, I need these servers up, and so I wanna override these schedules.” Spin ’em up, the servers are up, it does all it needs to do, and at the end, it just either shuts them down or, if you don’t shut them down, then basically, if you only did an override, let’s say, for two hours? At the end of the two hours, we’ll revert back to our original schedule, so that way you don’t have to remember to turn the lights out when you leave the room, right? So, we actually can shut things down for you.

    Shimel: Excellent. And Chris, give me an idea of—so, when you guys are engaged, I mean, with that kind of API, with that kind of integration into the DevOps toolset, you’re probably getting a decent view of how DevOps teams are using ParkMyCloud. And you’ve given us some examples, here.

    Are there any—I guess what I’m trying to ask, are there any special things that the DevOps people are doing that perhaps waterfall or other types of technologies are not doing? Is there commonality? Is it very easy to say, “Oh, these guys must be doing DevOps, because here’s, you know, what they’re doing?” Have you noticed any of that?

    Parlette: Yeah.

    Chashper: Alan, before Chris answers, maybe I can jump in and give a quick lead-in to this.

    Parlette: Sure.

    Chashper: Sorry, Chris—hope you don’t mind.

    Parlette: Sure.

    Chashper: Actually, one of the things I wanted to say is that we don’t have DevOps people at all, and one of the reasons we’re using ParkMyCloud is because we’re actually—we’re not DevOps people. We don’t know what needs to be done. We don’t speak, you know, Chef or any one of those guys.

    So—but the fact that we could actually use ParkMyCloud and then the user interface they provided us with, the web client, at least it did for us, went away, and everything is handled at that level. So, for us, that was a big, big move forward.

    Shimel: Yeah, no—and that actually is a great point, Jonathan. And Chris, I’m sorry we hijacked you here for a second.

    Parlette: No problem.

    Shimel: But the problem is, in today’s market, frankly, hiring people who have Chef or Puppet or Jenkins or, you know, DevOps skills sets is (a) hard to find, and (b) very expensive, right? And so, if you can deliver benefits like 50 percent savings on cloud usage or allowing some automation like this, it certainly is a lot easier. I don’t know of any engineering team that wouldn’t like that.

    But, you know, Chris, what do you see? I mean, are most of the people using the UI, or are they just you know, kinda going to APIs and stuff like that?

    Parlette: Yeah, and you know, as we get into larger customers, you know, it definitely is a mix of the UI and the API. The other change that we see, the mindset shift that we see from people is, especially as they’re moving from on-prem to cloud, a lot of people, when they’re used to—a lot of people, when they’re coming from a [Dog barks].

    Shimel: Hey, Jonathan, I think Chris might have shut off there for a second. Chris, you there?

    Parlette: Here we go. I’m back—I’m back. So, one of the things that, you know, as people are moving from on-prem to cloud, you get a lot of people who are used to leaving things on 24/7, because you know, on-prem, as things are left—you know, if you spin things up, it’s not an additional cost, really, to leave them on 24/7.

    And so, in this shift to the cloud, they have this shift of mindset where, if they’re being charged by the hour or it’s something that, you know, every hour that it’s left on is additional cost.

    Chashper: Yeah.

    Parlette: And so, when people are used to leaving things on 24/7, now the shift we have with people using ParkMyCloud, especially in an automated way, is to leave things off 24/7 and then kind of spin them up on demand. And so, that’s really where I think, you know, Jonathan and his team use that a lot, where things can be off, you know, turn on a schedule, but also just turn on on demand so, as the users have access to the UI and the API, they can turn things on on demand, as opposed to having to turn things off on demand.

    Shimel: Fantastic. Well, guys, you know, as I told you off mic, the time here goes really quick. [Laughter] We’ve already been on 18 minutes, beyond the 15 minutes I told you we would do, so we’re gonna need to wrap this one up right here. But first of all, Jonathan Chashper, CEO, Founder of WolfPack, it’s WolfPack.run is the URL, correct?

    Chashper: Yes, absolutely—thank you.

    Shimel: Thank you. Thank you for sharing with us today and giving us a little peek behind the kimono of how you guys are using ParkMyCloud. Continued success for any of our motorcycle riding friends or any group out there who—you know, I encourage you to check WolfPack out, it’s a pretty cool app.

    And Chris, thanks so much for sharing a little bit more, you know, a little behind-the-scenes look and a little bit more of a peek at, you know, ParkMyCloud and how it’s helping companies. Thanks for being on today’s DevOps Chat.

    Parlette: Yeah, Alan. Thanks for having me. I really appreciate it.

    Chashper: Alan—thank you very, very much. It was a pleasure.

    Shimel: Thank you, guys. You know what? We’re recording this right before Thanksgiving—have a happy holiday. Happy holidays to everyone listening! You’re probably listening to this after Thanksgiving, but it’s the start of the holiday season, so happy holidays, everyone.

    This is Alan Shimel for devopsy.kinsta.cloud and DevOps Chat. Hope to see you soon on another chat, and have a great day.

    — Alan Shimel

  • Mastering the Art of Cloud Migration

    Mastering the Art of Cloud Migration

    Cloud computing has come a long way over the years. Yet, only a few enterprises have managed to master the art of cloud migration. The secret to a successful migration lies in a well-defined, phased and iterative approach that not only streamlines the process but also accelerates the outcome. Here is one road map to assist others in transforming their migration journey:

    Phase 1: Plan

    Benjamin Franklin once said, “If you fail to plan, you are planning to fail.” Planning thus becomes the most critical part for a cloud migration program. Key focus areas in this phase include program management setup, portfolio analysis and cloud architecture and operating model layout.

    • Program management setup: The program management office (PMO) plays a major role in managing all aspects of the planning phase, from facilitating strategy building to program governance and benefits realization. The PMO ensures strong leadership commitment, sustained change management, program strategy alignment, rigor in project execution and decision-making governance.
    • Portfolio analysis: Analyzing the application portfolio helps in providing adequate representation of applications in scope. Application dependency information helps plan the sequence of application migration. It further pushes the business case for enterprise cloud migration.
    • Cloud foundation and operating model layout: The cloud foundation is comprised of landing zones. A landing zone is a standard set of secured cloud infrastructure with built-in policies, standards, guidelines and centrally managed services. Creating a strong foundation through landing zones is crucial for a scalable and sustainable enterprise AWS cloud model. As cloud computing becomes the paradigm for delivering business, technology operating models need to evolve and add more cloud-centric capabilities. A cloud operating model is the framework for putting core elements together in a more agile, productive and valuable way.

    Phase 2: Assess

    During the assessment phase, applications are analyzed in detail for future disposition. A cloud architecture and cloud operating model help lay the foundation for migrations. Consider the following:

    • Macroanalysis: Macroanalysis of applications, leveraging a proven cloud readiness and assessment framework based on business value, IT efficiency and cloud suitability ensures a clear migration road map. It also identifies enterprisewide concerns around security, networking, technical, operational, organizational, regulatory and financial.
    • Microanalysis: With the macroanalysis already performed, it is time for the deep dive. Microanalysis facilitates the understanding of current state architecture and defines cloud architecture based on patterns developed during macroanalysis. It concludes with the preparation of the detailed migration plan and effort estimates.
    • Cloud foundation and operating model design: The design should adhere to enterprise security and networking policies. Account and VPC structure needs to be designed based on cost allocation, resource management and ownership and security and compliance isolation. People, process and technology are the core elements of the cloud operating model. These should evolve to achieve cloud operating model goals, thereby increasing the value for the business and operations. People skills and experience are geared toward becoming more cross-functional, spanning a wider range of service components and use cases. Processes are then realigned around services instead of technologies, while tools and technologies are selected for effective implementation and automation of processes.

    Phase 3: Migrate

    During this phase, foundation cloud architecture and operating model are implemented, and the first set of applications identified as quick wins are migrated. The set should include a varying complexity of applications across different business units. Also, during this phase, it is important to take a proactive approach to change management. Consider the following:

    • Cloud foundation and operating model implementation: This step enables setting up landing zones including accounts, VPC, network connectivity, IAM Roles, policies and deployed workflow. Shared services and tools are also provisioned. In the cloud operating model, key processes are rolled out and teams are mapped to the new cloud-centric roles. This is followed by rolling out of subsequent processes leveraging the key learnings from the existing implementations. This ensures seamless integrations with current systems through the installation of selected tools.
    • Initial migration: The first set of applications is migrated as quick wins. The successful migrations help understand the portfolio and add to the confidence of the applications team. Importantly, it also lays down the foundation for repeatable migration patterns.
    • Change management: Effective change management is pivotal to the success of a cloud migration program. Change champions are involved to ensure co-creation of the future road maps and smooth cultural shifts. Continuous knowledge sharing and training is performed to evolve skills and include them in the transformation journey.

    Phase 4:  Scale

    After initial application migration, it is time for enhancing scalability and accelerating the cloud migration journey. While shifting the focus to scalability, it becomes important to keep a tab on cost and security. Consider the following:

    • Large-scale cloud migration: Harnessing the migration factory model is the best approach to target large-scale migrations. Based on the migration pipeline and supported by best-of-breed tools and specialized core/flex teams, it brings reliability and efficiency to the process.
    • Operating model optimization: Costs can escalate quickly. It is therefore essential to keep a check on it and optimize through policies, processes and moni­­­toring. It requires streamlining financial management by ensuring standardized tagging on all cloud resources.
    • Hybrid cloud model optimization: During this transition phase, both on-premises and cloud models are managed. The cloud model is further enhanced and optimized based on new services and tools.

    DevOps Automation – The Key Ingredient

    Cloud migration is a great time for enterprises to rethink their operational processes and improve the efficiency in managing and administering their portfolio. DevOps automation helps address the needs of a successful cloud migration while improving the operational efficiency of the services. This includes both infrastructure and application deployment automation. Additionally, standard templates and scripts significantly accelerate the buildout of future environments. DevOps also brings a number of business benefits including repeatability, auditability, significantly lower deployment risks and faster iteration cycles—all crucial to improved operational excellence, better security posture and improved competitive advantage.

    About the Author / Aarti Sahni

    Aarti Sahni is a technology leader with a wealth of experience in applying technical and operational expertise to create business value. Aarti’s expertise spans Practice Management, Cloud Computing, Architecture, and Program Management. In her current role at Virtusa, Aarti contributes to business growth by leading a number of pursuits and practice competency development. She also oversees several cloud programs ensuring desired outcomes for clients. Aarti has led a number of large transformations including cloud migrations, DevOps and cloud operating model to drive revenue, reduce costs and increase productivity. Aarti received a Master’s in Computers Application from Delhi University and completed an Emerging Leader Development Program at Columbia Business School in New York. Connect with her on LinkedIn.