devopsy.kinsta.cloud

Tag: Cloud Computing

  • FinOps Foundation to Help Rein in Cloud Costs

    FinOps Foundation to Help Rein in Cloud Costs

    A new consortium has been formed to promote best practices for controlling cloud computing costs.

    Announced at the Cloud Economic Summit, the non-profit FinOps Foundation counts among its founding members Atlassian, Autodesk, Cloudability, HERE Technologies, Just Eat and Nationwide.

    Cloudability co-founder J.R. Storment said the goal is to bring financial accountability to variable cloud spending that can easily spiral out of control if not monitored carefully. The adoption of best DevOps practices makes IT organizations more agile, but not every organization has the financial controls in place to ensure spending on cloud services is aligned with business outcomes, said Storment.

    These days engineers can use their corporate credit card to spin up virtual machines in the cloud. The FinOps Foundation is making a case for more accountability over the spending.

    Gartner estimates worldwide cloud spending will reach $360 billion by 2022, which is five times the compound annual growth rate for overall IT spending. The unfortunate truth, however, is that most finance organizations don’t have a lot of visibility into how those dollars are being allocated.

    To coincide with the launch of FinOps, 451 Research also published a survey of 300 IT and finance executives in the United States and the U.K. that finds more than half (57 percent) of large enterprises worry about cloud costs daily, with 80 percent admitting poor cloud financial management has had a negative impact on their business.

    In fact, the 451 Research report makes it clear most finance departments have little visibility into cloud spending. Almost three-quarters (72 percent) of finance executives acknowledged they have no formal reporting capacity between departments. More than half (51 percent) of respondents admitted to occasionally overspending and 68 percent said they are only alerted to overspend too late. A full 82 percent of finance respondents rely on cloud vendors, spreadsheets and manual processes to track cloud costs.

    Despite much of the variable cost hype surround cloud computing, 73 percent of the finance respondents in the United States and 81 percent in the U.K. still treat cloud as a fixed capital expense rather than an operating expense.

    To help finance teams better understand how cloud spending is being allocated, the FinOps Foundation will provide access cloud economic research and related articles, FinOps training and meetup groups. Early access to the forthcoming “Cloud Financial Management Strategies, Creating a Culture of FinOps” book published by O’Reilly Media will also be provided.

    As IT organizations increasingly employ multiple cloud platforms to run different classes of workloads, understanding the true cost of choosing to use one cloud over another will become more important. At the same time, IT organizations have a greater appreciation for the need to move workloads between platforms as costs rise. Just because an application workload was created in the cloud doesn’t mean that workload should be deployed there. Many long-running applications are less expensive to deploy in an on-premises IT environment. The challenge IT organizations arguably face going forward will be integrating streams of real-time financial data into DevOps processes to make more economically informed decisions about how to allocate their cloud resources.

    — Mike Vizard

  • Distinguishing Between Cloud Washed and Cloud Native

    Distinguishing Between Cloud Washed and Cloud Native

    Don’t fall for the marketing jargon: Running legacy infrastructure on a cloud instance is not actually cloud computing. Unfortunately, “cloudwashing” is common among enterprises as they attempt to jump on the cloud trend.

    So, how do we dispel the hype to distinguish pure cloud software as a service (SaaS), platform as a service (PaaS) and infrastructure as a service (IaaS)? In this article, we’ll define cloud washed and cloud native, citing NIST standard definitions and industry expert opinions. We’ll add some cues to help decipher cloud washed versus cloud native architecture as you search for new tech. No whitewashing here; prepare for some hard truths.

    What is Cloud Washing?

    In recent years, services that simply work over the internet were rebranded with the “cloud” buzzword, perpetuating a tenuous, vague perception of the cloud.

    Cloudwashed solutions are legacy, on-premises software held in a virtualized data center and rebranded as cloud software. Such tools originally were not built for the cloud and do not satisfy the NIST definition of true cloud computing.

    While non-local hosting can reduce maintenance and server costs, by adopting cloudwashed services you sacrifice the benefits of cloud native. As Clint Boulton, writing for CIO describes:

    “… the implementation doesn’t provide automated, continuous upgrades, let alone the multitenancy, self-service, auto-scaling and usage-metering capabilities that have come to characterize cloud services …”

    Cloud Native: What is True Cloud Computing?

    Cloudwashed is diametrically opposed with cloud native. To understand the true native cloud, let’s turn to the NIST official definition of cloud computing:

    “Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction.”

    NIST also defines three service models of cloud computing (SaaS, PaaS and IaaS), and specifies four types of deployment models (private, community, public and hybrid).

    As you can see, the NIST definition of cloud computing is specific. Authentic cloud services are configurable, providing hands-on optimization. They are elastic, able to provision and support multiple application requirements. Such cloud architectures are able to efficiently scale to the unique computing workloads of various applications.

    Furthermore, resources for cloud services are pooled. According to HiTechNectar, “True cloud platforms are built on a true multi-tenant model, with different physical and virtual resources dynamically assigned and reassigned according to consumer demand.”

    A cloud-native application (NCA) is thus an application specifically designed for the cloud that satisfies the definition of cloud computing. A true cloud solution would be a proprietary service built on a platform such as CloudStack or OpenStack. Google Cloud, Amazon Web Services and Microsoft Azure are all examples of authentic cloud providers.

    Cloudwashing Warning Signs

    Cloudwashing is rampant in the ERP realm. As HiTechNectar reports, “Many enterprise software vendors make claims that their applications are built for the cloud when they are not.”

    Thus, to avoid cloudwashed software, take heed of these warning signs:

    • Overuse of “cloud” in vague marketing jargon.
    • The need for custom integrations (this is against self-service).
    • No resource pooling.
    • Lack of developer tooling.
    • Lack of configurability.
    • Tooling not planned with redundancy in mind.
    • Server arrangement is not distributed.

    Good Signs of a True Cloud

    Thankfully, finding true cloud computing is made possible with the help from NIST, which lists five essential elements of cloud computing:

    • On-demand self-service.
    • Broad network access.
    • Resource pooling.
    • Rapid elasticity or expansion.
    • Measured service.

    Another good sign is the vendor’s involvement in the Cloud Native Foundation. Companies also dedicated to open source projects tend to be more progressive and transparent.

    Dissipating the Foggy Cloud

    A recent CompTIA Report found that half of the companies in 2018 have 31 percent to 60 percent of their IT systems in the cloud. Cloud computing is still driving the rise of cutting-edge trends including AI, blockchain and IoT.

    Unfortunately, though, not all purported cloud services are authentic. Ruled by an incessant need to stay relevant, tech marketing adopts and overuses certain jargon, and the “cloud” is not immune. Only by understanding the dichotomy between cloud washed and cloud computing can CIOs make educated decisions regarding their tooling choices.

    The NIST cloud computing criteria is valuable because NIST is an impartial standards agency. NIST computer scientist Peter Mell stresses the importance of evaporating this fog to reveal the truth:

    “… by adopting an authentic cloud, [businesses] are more likely to reap the promised benefits of cloud—cost savings, energy savings, rapid deployment and customer empowerment.”

    To avoid being cloudwashed, seek out multi-tenant architectures with self-provisioning, pay-per-use models, virtual instances and linear scalability. Only then will you reap the rewards of an authentic cloud-native environment.

    — Bill Doerrfeld

  • DevOps and Cloud: A Symbiotic Relationship

    DevOps and Cloud: A Symbiotic Relationship

    Most companies want to increase their competitiveness in today’s swiftly changing world, and so they cannot ignore digital transformation. DevOps and cloud computing have become two of the ways companies can achieve this needed transformation, though the relationship between the two is not easily reconciled—DevOps is about the process and process improvement, while  cloud computing is about technology and services. It’s important to understand how the cloud and DevOps work together to help businesses achieve their transformation goals.

    DevOps and Cloud

    Different organizations outline DevOps in different ways. This article does not debate which definition is correct, but rather presents them both to focus on the cloud’s benefit to DevOps. That said, DevOps definitions generally fall into two terms:

    1. In organizations it is defined as developer-friendly operations—IT operations are run separately yet in a way that is much more friendly to developers (e.g., self-service catalogs are provided to developers for stipulating infrastructure or providing technology-enabled pipelines for deploying new code).
    2. DevOps as a single consolidated team is habituated in organizations—developers take on operations responsibilities and vice versa.

    While cloud computing itself has several definitions, the most basic explanation of the cloud is a system that allows the provisioning of infrastructure (e.g., VMs or routers). Thus, it allows to being defined as code or templates, enabling the creation of repeatable processes that are not possible without cloud technologies.

    The aesthetics of cloud technologies and services become so easily amalgamated in DevOps vocabulary because they complement DevOps processes, regardless of how your organization defines them—or, regardless of which DevOps routes you travel to digital transformation with the cloud integration.

    Companies that focus on developers for operations often use cloud computing to speed developer productivity and efficiency. Cloud computing permits developers more control over their own components, resulting in smaller wait times. This application-specific architecture makes it easy for developers to own more components. By using cloud tools and services to automate the process of building, managing and provisioning through the code, service teams speed up the development process, eliminate possible human error and establish repeatability.

    Cloud computing also enables users to create self-service methods for provisioning infrastructure through AWS Service Catalog. Developers are able to quickly try new things, fail fast and just easily succeed in getting new products to market faster, without having to wait for IT operations to provision services for them.

    DevOps as a single term is really a mixture of these approaches, in which developers and operations work together using the cloud as a single common language. In this way, both the DevOps and cloud are able to work together, as everyone is learning new definitions and approaches at the same time. Developers and operations are equally cushy with the new language of the cloud, as developers often teach operations about the code aspect and operations can teach developers about infrastructure and security, developing a meeting point that leads to strong team dynamics.

    No matter the definition, the importance of cloud computing to DevOps can’t be accentuated enough. Cloud computing advances IT transformation, and with advanced tools and automation, it can enable companies to double down on their work to streamline and embed DevOps processes for greater efficiencies that are truly transformative.

    Inherently, as process improvement, DevOps also requires a culture change. Cloud computing can play a role here, as it can help codify and automate new processes. For example, if there is a new way in which developers should cluster the components they need to deliver a service—such as code, configuration, libraries and pipeline definitions—advanced automation tools can streamline the process and make it distinctly repeatable.

    The business case for DevOps combined with cloud technology for a successful IT transformation is fivefold:

    1. Bring products to market faster through faster access to development environments and streamlined developer processes.
    2. Automation and architecture as code reduce cloud complexity and even system maintenance.
    3. Add high security with automated, repeatable processes that serve to eliminate inaccurate error and, even more importantly, develop security controls from the very beginning.
    4. Reduce downtime through cloud-based continuous operations. Moreover, in the process of applying automation, developers can build stateless cloud application development, which increases availability and failover ability, in the process increasing business reliability and customer satisfaction.
    5. Increase scalability. One of the main reasons organizations look to cloud computing in the first place is its scalability, which allows organizations to increase capacity with the click of a button. When combined with DevOps, scalability becomes an integral part of applications as they are developed, while reducing the cost of infrastructure and increasing global reach.

    Get Past the Changes

    Together, DevOps and cloud computing are a powerhouse. While each offers greater effectiveness and business impact, together they are able to drive meaningful IT transformation that directly impacts business goals, regardless of the DevOps definition.

    At the same time, culture within the enterprise and among developers must change around the nuances of DevOps and its role in driving cloud development. Finally, IT companies must invest in these technologies and do so without an immediate goal—which, of course, drives corporate leaders and shareholders crazy.

    However, the alternative is doing nothing, which means certain failure. Competitors are likely to pull ahead in terms of time-to-market with solutions and application services. When you can hold up applications and processes in near real-time and do so within an elastic and efficient environment, the market will reward you for putting that effort. If you haven’t commenced on the process yet, it’s time to get started.

    — Jaymin Vyas

  • How Cloud-Native Computing Is Changing IT Job Roles

    How Cloud-Native Computing Is Changing IT Job Roles

    The cloud native age is upon us. This means not only that infrastructure, application deployment and security strategies look very different than they did just a few years ago, but also that the way companies design and fill IT jobs has changed—or should change, at least, for those seeking to stay relevant in our fast-changing, cloud-centric world.

    Which types of new roles are emerging in the cloud-native age? What should employers and employees be doing to make sure that the roles they design and fill meet today’s needs? Keep reading for insight into these questions.

    Traditional IT Job Roles

    Traditionally, IT job roles have been pretty consistently and clearly defined. They broke down into two main groups.

    First, there were developers—who may also have been called software architects, application programmers or software engineers. Whatever the exact job title was, the role centered on designing and writing code.

    Second, there were support people. They might have been called sysadmins, tech support, problem analysts or IT Ops. Their roles could include end user support, backend system management or both. In any case, their task list was limited primarily to deploying and managing software that was written by other people.

    There are a variety of traditional IT job roles as well, such as business analysts, network engineers and security analysts. But programmers and sysadmins were the two main types of IT positions that virtually every organization filled; the other roles addressed specialist needs that may or may not have been a requirement at a given organization.

    The Rise of the DevOps Engineer

    The DevOps movement has changed IT job roles a bit over the past decade. Inspired by the DevOps mindset, companies have moved to create roles that blend development and IT Ops together.

    This is where the SRE and DevOps engineer roles (for both of which there are hundreds of available positions on Monster.com at the time of this writing) came from.

    Yet, although the DevOps movement has spawned the creation of these new roles, it hasn’t killed off traditional IT job titles. People who specialize in just development or IT Ops can still find plenty of jobs.

    Cloud-Native Computing and the Future of IT Job Roles

    That may not remain the case in the future. As the trend toward cloud-native computing redefines everything about the way applications are designed, deployed and managed, the viability of traditional IT job roles is somewhat in doubt.

    To be clear, when I mention cloud native computing, I am referring to the present era in which virtually everything is designed to run by default in the cloud. I’m not suggesting that everything runs in the cloud; that is obviously not the case. What I mean is that we are living in a time when the norm is to deploy in the cloud (often using next-generation infrastructure technologies such as containers or serverless) and conventional on-premises infrastructure has become the exception.

    In an age when sophisticated cloud-based deployment environments have emerged as the default, IT job roles need to change. The landscape as it currently exists (where most professionals fall into either the developer or IT Ops camp, and a handful of DevOps engineers or SRE positions help to unite them) no longer works well.

    Why? Because in the cloud-native age, it is becoming increasingly difficult to fulfill a job role competently without a meaningful understanding of both application development and IT Ops. And having a few SREs on staff is no longer enough to bridge the gap.

    For example, if you want to deploy an application in a container, you’re going to need to know something about scripting and possibly infrastructure-as-code. At the same time, if you are writing application code that will run inside a container, you’ll need an understanding of how containerized infrastructure works, how to break down stateless from stateful components, how to implement communication between microservices and how to handle the unique security challenges associated with containers and microservices.

    In other words, it would be pretty hard to write or deploy a secure, well-designed, efficient containerized application without having some mastery of both software development and software administration.

    On top of this, cloud-native deployments also often require expertise in areas including software-defined networking or scale-out storage. Unless your company hires engineers who specialize in those specific areas (which is often not realistic or efficient, because the company may not need full-time positions in those niche roles) the rest of your IT staff will need to be able to address this need.

    To make things even more challenging, your IT team needs to be able to achieve all of the above while keeping pace with the rapid demands of continuous delivery. Typically there is little time to step back and make a plan for addressing unexpected skills gaps if you don’t have the right roles from the get-go.

    Conclusion

    Ultimately, what all this means is that we are moving toward a future where IT job roles will increasingly involve a broad mix of diverse skills, and specific specializations will become less common.

    That’s not to say that specialist IT job titles will entirely disappear. Some companies will always have a need for people who only do programming, only do system administration or only do software testing, for example. But creating, deploying and managing a cloud-native workload often requires each team member to possess a mix of specific skills that don’t align cleanly with traditional IT job roles.

    That’s why companies need to start hiring for this type of role (call it Cloud-Native Engineer, if you like), and IT professionals should begin preparing to fill it.

    — Ben Bernstein

  • Cloud Computing and the Concept of DevFinOps

    Cloud Computing and the Concept of DevFinOps

    The formation of DevOps brought together two distinct worlds, causing a shift in IT culture that can only be made better (and more cost-effective) by the integration of financial strategy. Enter DevFinOps. I say this only partially in jest. As long as the public cloud remains a utility, everyone should be responsible for controlling the cost of their cloud use, meaning “continuous cost control” should be integrated into the processes of continuous integration and delivery.

    Companies should at least start thinking of financial management as an element in the DevOps process. Time and time again, I see DevOps teams overspend and face major organizational challenges when inevitably the finance team (or the CTO) starts enforcing a stricter budget. Cost control becomes a project, derailing forward development motion by rerouting valuable resources toward implementing spend management processes.

    It doesn’t have to be this way. As financial resources are finite, they should be an integrated element from the very beginning when possible. There are a number of ways that finance can be integrated into DevOps, but one near and dear to my heart is with automated cloud cost control. A mental disconnect between cloud resources and their costs causes strain on budgets and top-down pressure to get spending under control.

    Changing the Mindset: Cloud is a Utility

    The reason for this disconnect is that as development and operations have moved to the cloud, the way we assess costs has changed profoundly in the same way that infrastructure has changed. A move to the cloud is a move to pay-as-you-go compute resources.

    This is due to the change in pricing structure and mindset that happened with the shift from traditional infrastructure to public cloud. As one of my customers put it:

    “It’s been a challenge educating our team on the cloud model. They’re learning that there’s a direct monetary impact for every hour that an idle instance is running. The world of physical servers was all CapEx-driven, requiring big up-front costs, and ending in systems running full-time. Now the model is OpEx, and getting our people to see the benefits of the new cost-per-hour model has been challenging but rewarding.”

    In a world where IT costs already tend to exceed budgets, there’s an added struggle to calculating long-term cost estimates for applications that are developed, built and run on a utility. But wasn’t the public cloud supposed to be more cost-effective? Yes, but only if every team and individual is aware of their usage, accountable for it and empowered with tools that will give them insight and control over what they use. The public cloud needs to be thought of like any other utility.

    Take your monthly electric bill, for example. If everyone in the office left the lights on 24 hours a day and 7 days a week, those costs would add up rather quickly. Meanwhile, you’d be wasting money on all those nights and weekends that your beautifully lit office is completely empty. But that doesn’t happen because in most cases, people understand that lights cost money, so people have automated this process in the office by using sensors either based on motion (usage) or time-based schedules. Now apply that same thinking to the cloud and it’s easy to see why cost-effectiveness goes down the drain when individuals and teams aren’t aware or accountable for the resources they’re using.

    Financial decisions regarding IT infrastructure fall into the category of IT asset management (ITAM), an area that merges the financial, contractual and inventory components of an IT project to support lifecycle management and strategic decision-making. That brings us back to DevFinOps: an expansion of ITAM, fixing financial cost and value of IT assets directly into IT infrastructure, updating calculations in real time and simplifying the budgeting process.

    Why This is Important Now That You’re on Cloud

    DevFinOps proposes that a more effective way to estimate costs is by breaking them down into smaller estimates over time as parts of the work get completed, integrating financial planning directly into IT and cloud development operations. To do this, the DevOps team needs visibility into how and when resources are being used and an understanding on opportunities for saving.

    As I have noted, the public cloud is a utility—you pay for what you use. And with that in mind, the easiest way to waste money is by leaving instances or VMs running 24 hours a day and 7 days a week. The easiest way to save money is just as simple: turn them off when they’re idle.

    — Jay Chapel

  • DevOps and Cloud: A Symbiotic Relationship Aimed at Business Success

    DevOps and Cloud: A Symbiotic Relationship Aimed at Business Success

    DevOps and cloud computing are not mutually exclusive, though their relationship has often been uncertain and confusing from a layman’s perspective. While cloud computing relates to technology and services, DevOps is more about processes and process improvement. However, both DevOps and cloud computing are vital in every organization’s journey toward an effective digital transformation.

    Cloud-centric DevOps Automation

    Cloud computing’s centralized nature enables a standard and centralized platform for DevOps automation. Using a cloud platform resolves issues in centralized software deployment caused by the distributed nature of enterprise systems.

    DevOps objectives including continuous integration (CI) and continuous delivery (CD) are supported by most of the private and public cloud service providers. This ensures centralized governance and control, in addition to reducing the costs associated with DevOps automation on-premises. DevOps utilizes orchestration systems that can proactively monitor the cloud data sets and application workloads. End-to-end automation is a prerequisite for deriving the full advantage from the cloud.

    By expanding the concept of continuous improvement to cloud-based platforms, DevOps ensures lesser system vulnerabilities and greater security.

    DevOps Best Practices for Effective Cloud-Based Computing

    DevOps provides several core capabilities that assist organizations in effectively handling cloud challenges. These include:

    • Infrastructure as Code (IAC): IAC comprises the provisioning of servers and installation of application code, the core components of the system architecture.
    • Automated Application Deployments: DevOps practices facilitate the creation of a fully automated application deployment pipeline that is of great importance in the development life cycle.
    • Application Lifecycle Management (ALM): DevOps principles such as continuous integration and delivery help in effective ALM in the cloud.
    • Continuous Quality Assurance (QA) and Testing: DevOps capabilities address the challenges for QA and testing in the cloud by provisioning multiple test environments using cloud-based resources that result in enhanced quality and productivity.
    • Knowledge-Sharing with the Cloud Provider: DevOps promotes the concept of knowledge sharing between organizations and SMEs of the cloud service providers throughout the application life cycle using online communities that are focused on fostering communication and collaboration, thereby ensuring that most risks are mitigated effectively.

    The Significance of Cloud Computing vis-á-vis DevOps

    Cloud computing complements DevOps in several ways. The application-specific infrastructure in the cloud enables developers to own more components easily and enhance their productivity and efficiency. It allows developers to create the development environments quickly without the need for IT operations to provision resources and infrastructure.

    Cloud computing ensures flexible IT infrastructure in addition to enabling greater business agility. It propels IT transformation by helping organizations in streamlining and embedding DevOps processes.

    DevOps tools and services eliminate human error and help in establishing repeatability by automating and streamlining the process of building and managing code.

    IT Transformation Enabled by DevOps with Cloud Technology

    Cloud computing coupled with DevOps ensures that scalability becomes an integral part of application development, thereby contributing to reduced infrastructure costs and increased global reach.

    Cloud-based operations increase the availability and failover ability of applications in addition to eliminating downtime, which leads to improved business reliability and rise in customer satisfaction.

    DevOps automation and IAC help in reducing the complexity of the cloud and improving system maintenance. Additionally, the automated repeatable processes increase security controls. Process streamlining and faster access to the development environments ensure improved product time to market.

    In Conclusion

    By realizing the importance and prioritizing the usage of DevOps in the cloud, organizations can derive a huge number of potential benefits including enhanced agility and reduced operational costs.

    — Veritis

  • VMware Adds More DevOps Depth to Cloud Strategy

    VMware Adds More DevOps Depth to Cloud Strategy

    VMware today added a bevy of services to its portfolio that make managing instances of its software running in a public cloud easier.

    Additions to the VMware cloud portfolio include VMware Hybrid Cloud Extension Service for Private Cloud, a software-as-a-service (SaaS) offering that enables IT organizations to employ a self-service portal to move workloads between public clouds in a way the minimizes downtime.

    Other additions include the ability to apply both the Wavefront by VMware monitoring service and VMware Cost Insight Service against VMware Cloud on AWS, in addition to other public clouds. VMware has also added 45 integrations to expand the number of processes this SaaS application can monitor.

    Finally, VMware has added a VMware Log Intelligence Service to provides access to real-time analytics of log data.

    The arrival of these services coincides with the availability of VMware Cloud for AWS in the London region of AWS, which will be followed by the VMware stack becoming available in the Frankfurt, Germany, region of the AWS cloud.

    Chris Wolf, vice president and CTO of global field and industry for VMware, said that as more organizations look to move out of data centers they operate, they are asking VMware to extend the mobility capabilities the company developed for its hypervisor into the public cloud. In fact, many of them are now moving to deploy VMware software across multiple clouds, he said.

    Naturally, that expansion of VMware beyond the local data center is creating a raft of DevOps challenges, many of which the company is trying to address by making available a series of SaaS applications under the moniker VMware Cloud Services.

    VMware is making a concerted effort to expand its DevOps portfolio at a time when many developers have shifted application workloads onto public clouds based on virtual machines other than VMware. Obviously, VMware has developed many partnerships with cloud service providers. But the number of VMware hypervisors running in public clouds remains a relatively small percentage of the total number of hypervisors. VMware is hoping that will change, however, once developers discover VMware hypervisors on public clouds, which in many cases can reduce the headaches associated with trying to manage hybrid clouds based on disparate hypervisors. As part of that overall strategy, VMware also has been aggressively embracing emerging cloud-native platforms such as Kubernetes that can run anywhere.

    Most enterprise IT organizations are still learning to walk when it comes to hybrid cloud computing. The most common use case is still disaster recovery. Most IT organizations are a long way from dynamically moving workloads between clouds. Most of the use cases for moving workloads initially will be confined to simply lifting a workload from an on-premises environment. But as IT organizations also gain more experience, soon there may be as many workloads moving between clouds as there are workloads moving between servers in a local data center.

    — Mike Vizard

  • 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.

  • Today’s DNS: DevOps’ New Best Friend

    Today’s DNS: DevOps’ New Best Friend

    Continuous development and deployment is a primary focus of DevOps teams. As part of this process, DevOps teams also require the automatic creation or removal of networks, and automated deployment to production. Automation is a closer guarantee that the process will be done right the first time because the fewer the number of manual steps involved, the less likelihood for human error. Intelligent DNS improves DevOps project life cycles by integrating DNS tasks into your software development and automation tools.

    DNS Needs an Upgrade

    The internet has come a long way since its humble beginnings, from the Advanced Research Projects Agency Network (ARPANET) of the 1960s to an entity that is mission-critical for the world’s commerce. This system is now tested and taxed in ways that were not even conceived of when it was originally designed. One of these early elements, DNS, is now a potential bottleneck for network performance in general and DevOps teams in particular.

    One of the benefits of cloud computing is that it enables DevOps teams to automatically create and remove servers as needed for development and testing. Infrastructure as code (IaC) enables cloud computing to build infrastructure automatically using robust APIs that build servers and add applications as needed. Traditional DNS, with its mostly manual management, becomes a bottleneck for this automated rapid configuration of infrastructure. This is why organizations need an intelligent DNS solution. Intelligent DNS with a robust API can seamlessly interface with current DevOps software, removing the bottleneck that traditional DNS can become.

    Extending Agile with DevOps

    The underlying ideas of agile programming are extended with DevOps. Rather than the traditional way of producing and testing the code, then tossing it over the wall to the network operations team to deploy, DevOps merges the development, testing and operations responsibilities. In short, DevOps should have the ability to break the silos within your IT environment and among the development, QA and operations teams.

    DevOps’ blend of cultural philosophies, practices and tools increases an organization’s ability to deliver applications and services at high velocity. DevOps allows organizations to evolve and improve products at a faster pace than organizations using traditional software development and infrastructure management processes. This speed enables organizations to better serve their customers and compete more effectively in the market.

    Rapid Change Propagation is Essential

    In addition to rapidly delivering applications and services, a goal of DevOps continuous release is to remove bottlenecks to the development, testing, and deployment cycles. This is aimed at creating an environment where the work isn’t hampered with computer delays and frustrations.

    When you’re automating the creation or deletion of 100 virtual servers with a single mouse click using IaC, waiting for 30 minutes to see if DNS changes appear at the edge servers delays your project. Your DNS needs to move as fast as your IaC software and service discovery processes. At this point, intelligent DNS with rapid change propagation becomes essential. When choosing DNS vendors to support your DevOps environment, make sure to include speed testing for the network’s propagation for changes.

    Where IaC Comes In

    The aim of DevOps professionals is to create and sustain server environments that closely resembles the way software developers build and maintain application source code. IaC is the way DevOps teams make that happen.

    IaC is based on three primary constituents:

    • Unit/Integration Testing – Lets you validate your infrastructure code within various phases of the DevOps pipeline and lets you feel confident about what you are pushing to production.
    • Infrastructure Blueprints – Supports the reusable, consistent and rapid deployment part of IaC.
    • Version Control – Facilitates the method track and rollback changes to your infrastructure as needed.

    Infrastructure blueprints can be created using configuration as code (CaC). Using tools such as Terraform, Ansible and Chef allows DevOps teams to build these blueprints by enabling a declarative way of handling infrastructure configuration. Infrastructure blueprints should always go hand in hand with unit/integration testing. Having a robust, API-driven DNS network to couple the full automation of DNS changes alongside the infrastructure and configuration changes ensures a smoother process.

    IaC is next-generation technology for DevOps environments. When combined with CaC products, it changes the way software is built and delivered. Continuous integration and continuous deployment are a large part of the DevOps world that all still depends on DNS technology to connect everything on the network.

    The Role of Service Discovery

    Service discovery is needed to enable your apps or servers to identify which services are available on the network and which IP addresses and ports are associated with them. Previous methods of tracking this information no longer work in the DevOps age.

    Since modern infrastructure is so scalable and changes so quickly, keeping track of service information inside a periodically updated database doesn’t work anymore. Instead, you have to be able to discover services in real time and update your service information continually. Three common service discovery tools are: Consul, Apache Zookeeper and Etcd (with Registrator and confd).

    A tight integration with your managed DNS provider as part of your overall strategy means that service discovery can work hand in hand with the DNS configuration so both systems remain in sync.

    Moving Toward Intelligent DNS

    DevOps needs the same types of robust features you would want for your external internet traffic: end user-facing DNS. You should align with a vendor that can provide the flexibility, agility and reliability you require to deliver your applications.

    Look for features including:

    • Zone Transfers allowed and easily facilitated
    • An anycast DNS network
    • A robust API to support automation, IaC, service discovery and other architecture and tool needs
    • Native integration with common DevOps tools such as Terraform, Ansible and Chef
    • An SLA that meets your needs for reliability and performance

    These elements are necessary, but a more important item on your checklist needs to be redundancy in all layers of the stack, including DNS. Because no vendor is completely bulletproof, use at least two authoritative DNS providers to set up redundancy. Following these guidelines will improve your DevOps’ life cycle by using intelligent DNS.

    About the Author / Kimberly Lacerte

    Kimberly Lacerte has 14 years of experience in computer and technical writing. She is currently the Content Marketing Manager at NS1 in Bedford, N.H. Previously, she has written for Veritas, Symantec, Health Dialog and Dyn. Kimberly holds an English BA from UNH and an MBA from Southern NH University.

  • VMware Moves to Automate Management of Hybrid Clouds

    VMware Moves to Automate Management of Hybrid Clouds

    Moving to expand the reach of its portfolio of IT management software well beyond virtual machines, VMware today announced that the vRealize suite of IT automation tools can be employed across containers and virtual machines running on-premises or in a public cloud.

    In addition to providing support for VMware’s Admiral container management portal, version 7.3 of vRealize Automation adds much tighter integration with both Amazon Web Services (AWS) and Microsoft Azure public clouds. For Microsoft Azure, vRealize now can deploy and manage middleware and application services. For AWS, vRealize Network Insight now can microsegment networks in an AWS Virtual Private Cloud as well as troubleshoot network traffic issues in AWS.

    From a DevOps perspective, however, the most significant new capability is being added via an update to the vRealize Operations module: the ability to automatically deploy workloads across multiple clusters and datastores based on business policies defined by the IT organization, says Mahesh Kumar, senior director of product marketing for VMware. This update also adds a predictive Distributed Resource Scheduler (pDRS) that leverages analytics provided via vRealize Operations to predict anomalies and identify potential I/O contention issues before they occur.

    At the same time, the latest update to VRealize Operations will incorporate a tab for vRealize Business for Cloud 7.3, which has been extended to provide cost and capacity utilization metrics for AWS and Microsoft Azure alongside VMware-based private cloud costs.

    Other additions to the VMware portfolio include tighter integration between VRealize Operations and VMware vSAN storage software, NSX network virtualization software, enhanced blueprints for sizing deployments and integration with configuration management tools from Puppet. Kumar says that latter capability will be extended to include support for Chef and Ansible configuration management tools as well.

    With these additions to the IT automation portfolio, VMware is clearly signaling its ambitions lie beyond its own hypervisor. Within enterprise IT environments VMware is dominant. That position has enabled it to gain significant traction in terms of driving adoption of its management tools. Now, VMware is moving to extend the reach of those tools into public clouds and containers. At the recent Dell EMC World 2017 conference last month, VMware debuted instances of its portfolio of software running on AWS. Most containers today are deployed either on top of a virtual machine or in a platform-as-a-service environment. But VMware is also aware of the fact that over time more containers will be deployed on bare-metal servers that are not running any type of virtual machine software at all.

    Of course, just about every other provider of an IT management framework knows this as well. In addition, there’s no shortage of management tools designed specifically for containers. But as DevOps continues to evolve, most IT organizations are naturally expected to favor approaches that enable them to manage the broadest number of platforms possible.

    — Mike Vizard