devopsy.kinsta.cloud

Tag: Multi-cloud

  • The Inevitability of Multi-Cloud-Native Apps

    The Inevitability of Multi-Cloud-Native Apps

    We all know the story: Enterprises moved to the cloud. They learned about data center virtualization and multi-tenancy and self-service developer provisioning. Along came Kubernetes, and they moved to cloud-native, where they learned about automation, DevOps and infrastructure-as-code (IaC). Now, even though most enterprises are still figuring out how to do cloud-native at scale, there’s a new imperative they must master: Multi-cloud-native applications. And for almost every enterprise with a global footprint, the move to multi-cloud-native applications is not optional—it’s inevitable. 

    But before we explore why this is the case, let’s first retrace our steps. For almost every enterprise out there, the journey to the cloud started with adopting a public or private self-service infrastructure provisioning and management model. These enterprises quickly realized that this new IT model required a new set of tools to solve challenges they’d never before faced—enabling their developers with self-service provisioning, managing and operating infrastructure. Enterprises figured it out, but as soon as they figured out the cloud, they quickly had to gear up for the second phase: Automating and operationalizing an enterprise-wide rollout of cloud operating models throughout their entire developer organization. 

    Of course, this phase has its own set of challenges, and a rich ecosystem of tools emerged to address them. Even so, we all can agree that the majority of mainstream enterprises are still in this second phase. They’ve adopted cloud, they’ve expanded its use, and they’re grappling with the challenges around multi-tenancy, security, DevSecOps and governance. Hand-in-hand with this goes a whole new set of challenges around cost management. Suddenly, enterprises are faced with managing the variable costs of public cloud infrastructure: Optimizing compute infrastructure, utilization and capacity to rein in cloud spend. It’s an issue Sarah Wang and Martin Cassado took head-on in their research on the Trillion-Dollar Paradox.

    So, enterprises moved to the cloud and are now, for the most part, successfully grappling with scaling it. But nothing stays the same for long, and businesses drive IT to innovate. This is where cloud-native entered the picture to help enterprise software development teams become more agile and help businesses transform to deliver new services and experiences faster. In fact, the consumer experience this model makes possible has rapidly become the norm.

    Consistently delivering rapid software iteration across a global footprint forces DevOps organizations to grapple with an entirely new set of technical challenges: Leveraging containerized applications and microservices architectures in production across multiple Kubernetes clusters running in multiple geographies. Customers want an on-demand experience. This third phase is what we call multi-cloud-native, and it was pioneered by hyperscale IaaS players like Google, AWS, Azure and Tencent.

    The reality is, of course, that hyperscalers aren’t the only ones who have figured out how to deliver multi-cloud-native apps. Webscale innovators like Doordash, Uber, Twitter and Netflix have done it, too. To get there, they had to make and share their multi-cloud-native apps across every geography where their customers live. And, in turn, to make that happen they had to tackle a new set of challenges: Develop new tools and techniques like geographically distributed, planet-scale databases and analytics engines, application architectures that run apps on the backend close to the consumer in a multi-cloud-native way. This enabled them to do arbitrage across fleets of infrastructure capacity across regions, all while giving their customers that instant experience they increasingly grew to expect.

    What enterprises must realize is that this experience consumers have grown to expect from webscalers is rapidly becoming the same experience they expect when accessing their bank account, their insurance apps and their tax records. For almost every planet-scale enterprise, this sets up a whole new set of challenges: To span multiple clouds and multiple geographies running multiple Kubernetes clusters, you now must worry about new ways to do autoscaling, self-healing, disaster recovery, operations management and cost optimization—all of which are things that you’re just now getting figured out for virtual machines (VMs) and clusters in single regions.

    Enterprises must face the reality that cloud-native application models are not the destination but rather a waypoint on a journey to becoming multi-cloud-native. Because the consumer experiences delivered by webscalers make this the inevitable destination.

    The Enterprise Journey: Cloud, Cloud-Native and Multi-Cloud-Native

    Don’t take my word for it.

    Uber and Twitter public disclosures describe how the multi-cloud-native model is an integral part of their strategic game plan. Hybrid and multi-cloud are part of this, too, leveraging Kubernetes as a cluster manager, but they still need tools to manage all those clusters across multiple environments in multiple regions at planet scale.

    The bottom line is that the architecture that webscale companies are using today is the same one enterprises will need to adopt tomorrow to remain competitive. Alternatively, these enterprises will cede market share and relevance to the next webscale innovator to disrupt an industry. In adopting this model of building multi-cloud-native apps, enterprises will have to deal with unified access management, controlling multiple clusters, resource management and more, all across multiple regions and clusters of capacity, aggregating versus disaggregating cluster resources, using logical services that span clouds versus namespaces that span a single cluster.

    The Enterprise Solution: Planet-Scale Cluster Manager

    They will need a planet-scale cluster manager to do this; something that can observe costs, operations, performance and SLAs across clusters, across public and private clouds, spanning VMs and Kubernetes through a single pane of glass so they can operate above the clouds in an automated, easy-to-use way. Band-aid solutions like running multiple spreadsheet models to figure out how to optimize are not scalable. What’s needed are tools like machine learning to automate and optimize at scale, bin packing technology to intelligently and automatically optimize across a planet-scale infrastructure fleet and high levels of automation either with humans in or out of the loop. That’s how hyperscalers and webscalers are already doing it.

    Every planet-scale enterprise is multi-cloud-native, running data-driven apps. It’s not a fiction: It’s already happening across webscale companies, not just hyperscalers. Multi-cloud-native is the path that every enterprise is going to need to follow if they want to transform themselves to compete with the next webscale upstart. The good news is, the pioneers have left us a map to follow.

    To hear more about cloud-native topics, join the Cloud Native Computing Foundation and the cloud-native community at KubeCon+CloudNativeCon North America 2021 – October 11-15, 2021

  • 4 Tips To Plug The Cloud IT Skills Gap

    4 Tips To Plug The Cloud IT Skills Gap

    Technical talent is few and far between. The programming world faces a developer shortage, and with this shortage comes a lack of cloud know-how. By now, most organizations have become multi-cloud, yet 86% of IT professionals believe a lack of these skills will slow down cloud projects.

    As more teams transition from older architectures to cloud environments, the IT skills gap could pose a severe bottleneck to software development and deployment. Cloud servers require ongoing maintenance, and managing security and compliance is challenging, even for seasoned developers. Furthermore, it’s easy to overspend in the cloud—without keen insight into vendor nuances, it becomes challenging to select the most cost-effective package for the application at hand.

    I recently talked with Joe Spurrier, chief technology officer and co-founder, cloudtamer.io, to see how teams can improve their cloud strategies while navigating a short supply of IT cloud know-how. According to Spurrier, increasing automation, sharing reusable templates, centralizing best practices and maintaining agnosticism are strategies to amplify cloud results. Below, we’ll expand on these areas to see how they maximize cloud benefits while retaining a lean engineering footprint.

    Automation, Automation, Automation

    “Automation is key to furthering your adoption and use of the cloud,” said Spurrier. The drive to automate comes as no surprise to many DevOps and SRE professionals whose goal is to automate their job away. When automating the cloud, infrastructure-as-code (IaC) is a fundamental necessity. “If you’re getting into cloud, you should probably have some scripting skills,” said Spurrier.

    Automation can significantly aid scalability when setting up additional accounts since engineers must replicate similar operations, such as server provisioning, deployment patterns, monitoring and so on. Automation is also essential for shift-left testing and to increase observability into production environments. “It’s one thing to deploy an application via automation, but another to have tests in automation—that’s the next level,” said Spurrier.

    Now that so many tools are API-driven, orchestration becomes programmable. A cloud service provider’s CLIs or SDKs could also be leveraged to hook into these integrations to construct such automation.

    On the flip side, too much automation for high-level privileges could backfire. “Someone could break into a data center, steal a server, disconnect it, then run off,” Spurrier explained. Thus, automation will require a higher sense of security to ensure that every change is appropriately authorized and logged.

    Reusable Templating

    Along with automation, documenting operational processes to be shared amongst engineering teams is vital for maximizing efficiency in a lean talent landscape. The key here is to make the process self-documenting and reusable, stresses Spurrier. This will most likely involve someone on the team creating shared libraries and repositories for other team members to leverage.

    One such example is Amazon’s golden AMI pipeline. Golden AMIs are virtual machines that teams can “standardize through configuration, consistent security patching and hardening.” Golden AMIs can also enable a repeatable process for performing monitoring, logging and even distribution to business units.

    Reusable patterns are important for building CI/CD systems so that when you commit code, it is automatically deployed to preferred cloud providers. In general, Spurrier recommends building shared repositories that are easy to clone, with step-by-step instructions for usage. Sample applications that demonstrate components in different languages can also aid developer usability and save time.

    Adopt Centers of Cloud Excellence

    Another way to encourage better adoption is by creating a center of cloud excellence (CoCE). For an enterprise, having a cloud-centric project management group can be very helpful to organize knowledge and offer support. A CoCE could centralize operations, supply engineers with pre-configured containers and help distribute access to cloud accounts.

    A CoCE is a good way to start to unite disparate teams around shared best practices, said Spurrier. Depending on your organization’s needs and workloads, a CoCE will focus on varying skills, he added. In the beginning, a company may have just one center for cloud knowledge. However, as adoption grows, dedicated centers may likely emerge around specific cloud providers, too.

    Retain Agnosticism

    Contrary to popular belief, multi-cloud steups aren’t always about lift and shift. Business units often adopt a particular cloud to suit specific workload requirements. For example, researchers may choose GCP for its data science functions, or Microsoft shops may prefer Azure.

    In a multi-cloud world, management layers could help retain a modicum of vendor neutrality. For example, take Cloud Custodian, a tool developed at Capitol One and recently contributed to the CNCF. Using Cloud Custodian, engineers can run security checks across AWS, Azure and GCP and generate metrics for reporting. Such control and insights could empower teams to automate some of the multi-cloud management burdens.

    When working with multi-cloud, it’s also good to consider agnostic tooling that can work across different providers, like Terraform or Kubernetes, Spurrier said.

    Templating

    Cloud transformation is ongoing at most organizations. With this rise, more cloud-native processes and tools are emerging. Yet, with talent in short supply, DevOps isn’t always fully prepared. To review, we covered four ways businesses can circumnavigate this issue to get an edge:

    • Increased cloud automation is a necessary response to a slimmer labor pool. Though building automation requires upfront technical skill, it pays dividends in increased efficiencies.
    • Reusable libraries and templates can rapidly configure new projects and do so consistently across business units.
    • Consider maintaining a center of cloud excellence to centralize policies and offer support.
    • Opt for agnostic tools. This helps to retain vendor neutrality and apply consistent controls across clouds.

    Of these above strategies, Spurrier emphasized the importance of creating shared templates. When used right, a templating approach can be very effective, he says. “If you have a templating model, it should be easy for DevOps teams to migrate to new features. If you’re leveraging tools that set up templates, it’s easier to figure out how much infrastructure is going to cost.”

  • Majority of Organizations Now Adopt Multi-Cloud

    Majority of Organizations Now Adopt Multi-Cloud

    As IT’s digital footprint grows, its cloud footprint is rising both in size and complexity. As a result, most organizations have matured into multi-cloud operators. A multi-cloud approach empowers different divisions with the autonomy to select the right computing environment for their needs. It also enables a lift-and-shift ability to port workloads across cloud service providers (CSPs) when needed. Adopting a multi-cloud model could bring performance benefits, cost savings or better scalability, all while encouraging a more vendor-neutral stance.

    We’re in a multi-cloud world. A recent HashiCorp study found three out of every four organizations are already multi-cloud. This is a staggering increase from just a few years ago when mono-cloud was more accepted, and operators had zombie-like allegiance to AWS. The uptick in multi-cloud signals the maturity of offerings at other CSPs, like Azure and GCP. It also signals differentiation among clouds as each hones in their unique value propositions.

    HashiCorp’s inaugural State of Cloud Strategy Survey offers some very clear results about the state of multi-cloud adoption. Below, I’ll review major takeaways from the report to better understand the state of multi-cloud adoption. To sum it up, large organizations tend to benefit most from multi-cloud adoption, as there are still significant roadblocks to truly reaping a sizable return from a multi-cloud status. Yet, more infrastructure automation may help companies of all sizes respond to multi-cloud complexities.

    The Multi-Cloud Era

    DevOps truly operates in a multi-cloud era. The report revealed 76% of organizations are already multi-cloud; that leaves only one in four companies leveraging a single cloud. And, that trend won’t stop—within two years, 86% predict they will be multi-cloud operators. The study also confirms that the larger a company is, the more likely it will adopt multi-cloud—94% of large enterprises with 5,000 or more employees are multi-cloud.

    So, what’s driving this cloud fragmentation? Well, 34% of respondents cite digital transformation as a top driver for multi-cloud adoption. In the race to meet new digital innovation demands, multi-cloud has emerged as a strategic force. To enact this rapid change, many organizations are investing in a cloud center of excellence (CCoE) to guide cloud transformation efforts. A CCoE is most common within large companies with a cloud budget of $5 million or more.

    Speaking of budgets, cloud spending is going through the roof. In 2020, only half of companies met their projected cloud spend, and 39% of companies overspent their allotted cloud budgets. As I’ve covered before, cloud-native costs are notoriously difficult to identify and trim. Without the proper guardrails to manage spending, surprise data egress fees or hidden server costs can strain the cloud checkbook. As it stands now, 40% of companies lie in the $100,000 to $2 million per year range, and 6% of enterprises are investing $50 million a year or more into multi-cloud. This spending will likely increase in the coming years as cloud reliance expands.

    Enterprises Benefit Most

    So, which clouds are companies using? If we compare cloud adoption, AWS is a clear market leader; 88% of companies use AWS, 74% use Azure and 61% use GCP. AWS’s hegemony is not expected to fade in the next two years. Yet, while AWS usage will remain the same, competing CSPs will experience modest increases. This is likely due to Azure and GCP making gains in geographical zones outside North America, such as Asia-Pacific and Africa.

    In terms of technology used in cloud environments, open source software (OSS) is a popular choice. Cloud-native open source projects, such as Kubernetes, OpenStack and Terraform, have taken on a life of their own, with vibrant community support. However, not all shops build upon OSS and run it themselves. Somewhat ironically, we’re seeing more managed OSS emerge. One stand-out area is provisioning, where 42% of organizations build with open source and run it themselves.

    On the whole, multi-cloud is working at most enterprises, with 53% of survey respondents saying multi-cloud has helped achieve their business goals. The top benefit of multi-cloud is digital transformation, at 34%. This is followed by avoiding lock-in (30%), reducing cost (28%) and scalability (25%). But multi-cloud does not treat all companies as equals; the likelihood of multi-cloud success increases as the company size increases. Less than half (42%) of small companies say they have multi-cloud success, which jumps to 64% for large enterprises. With fewer resources for support, multi-cloud may be less beneficial for startups and small to medium businesses. In fact, 41% of professionals say a lack of in-house skills inhibits their cloud success.

    Challenges in a Hybrid Multi-Cloud World

    An ongoing talent gap is just one potential challenge to cloud success. Just over half (51%) say cost concerns are a top inhibitor to their cloud program success. Hybrid cloud complexity is another prominent challenge, with 35% of organizations citing it as a major cloud obstacle. Many enterprises are still grappling with the remnants of legacy on-premises estates. But technical debt is not the only reason for hybrid modalities. Surprisingly, large platforms even have constructed their own data centers or used colocation as an intentional strategy.

    Security is a top cloud inhibitor, according to 47% of IT professionals. The leading cloud security concerns include data protection (40%), data theft (33%) and regulatory compliance (31%). The myriad cybersecurity threats evolve each day, and cloud technologies are not immune; for example, web APIs are now a significant threat vector. A separate report found a 300% increase in malicious API traffic in the past six months. Other issues, such as exposed keys, insecure defaults and misconfigurations are known to hamper cloud-native infrastructure.

    Contrary to popular belief, nearly half (46%) of companies reported that COVID-19 has not quickened their cloud adoption. This reality could indicate that cloud migration has been planned for years, and recent adoption is only part of an ongoing trend. The study found that the pandemic did, however, accelerate things like infrastructure-as-code (IaC), container orchestration, compliance and governance and other operational factors.

    Infrastructure Automation Supports Multi-Cloud

    Multi-cloud feels like an inevitable result of accelerating cloud adoption in a more diversified market. Rising multi-cloud use is also arguably in line with Conway’s Law. As organizations develop more and more digital experiences across new verticals, the platforms and backend processes to support these initiatives will inevitably grow more and more complex.

    To mitigate some of the issues posed by multi-cloud, many organizations are turning toward increased infrastructure automation. In fact, 70% of those surveyed said infrastructure automation tools are extremely important to their organization. Of these tools, provisioning automation (75%) is the most popular kind in use. Automation for other areas, like networking (58%), security (50%) and app development (69%) follow.

    Hashicorp’s State of Cloud Strategy Survey boldly announces, “Welcome to the Multi-Cloud Era,” and its findings back up that sentiment. For further insights, you can view the results freely on this website.

  • Establishing Trust in Multi-Cloud Environments

    Establishing Trust in Multi-Cloud Environments

    Modern applications are transforming enterprises into digital innovation factories. However, the distributed nature and complexity of modern apps have made it extremely difficult for organizations to maintain trust and compliance across multi-platform, multi-cloud environments. 

    Although Kubernetes is the standard for application platforms today, each cloud service provider (CSP) has a different offering for infrastructure-as-a-service (IaaS) or their own platform-as-a-service (PaaS) with varying capabilities and APIs. Not only are these APIs incompatible (with the exception of Kubernetes if no vendor extensions are used), each infrastructure and platform are treated and managed in silos. These silos act as an isolated and non-overlapping administrative boundary,  preventing cross-boundary visibility and trust between microservices.  This makes it much harder for enterprises to know and consistently remediate their security posture across clouds and platforms, opening them up to attacks.

    To solve this problem, organizations are extending enterprise security controls to cloud environments. The problem is that application teams and security teams have traditionally had competing goals—agility versus risk and control—and security operations have not evolved at the same pace as application operations. This creates friction between the teams and forces application operation teams to make a choice: 

    1) Slow down application delivery and operations to reduce risk and miss out on the transformative benefits of multi-cloud or 

    2) Continue to develop and ship applications as quickly as possible without considering security and compliance. 

    Neither is a good option. To unlock the power of modern applications running in multi-platform and multi-cloud environments, organizations need to find a way to integrate security seamlessly throughout the software delivery life cycle at the speed users expect.

    Integrating Zero-Trust into the Application Delivery Cycle

    The key to securing applications in a multi-cloud world is zero-trust. Building zero-trust principles directly into modern applications allows organizations to identify threats early, reduce attack surfaces and ship security functions alongside the rest of the application stack—regardless of the underlying application platforms and cloud stacks underneath.

    In this use case, one of the key components of zero-trust is application segmentation; in other words, how to make access decisions between different applications or components of applications. Zero-trust must provide identity-aware, adaptative and on-demand access to any app from any user or app in a way that improves the flexibility and the agility of application access through a scalable model.

    Application segmentation must be provided to application operation teams so that they can embed it into their application quality processes as another gate. Application operation teams can do this by implementing application segmentation policies that identify workloads as they are created through rich, dynamic attributes. The more intrinsic/static attributes (IPs, digital certificates, namespaces, labels, etc.) and extrinsic/dynamic attributes (user behavior, workload behavior, network behavior, etc.) that are identified, the more fine-grained your access decisions can be. 

    Incredibly, application segmentation today continues to be done manually. But with millions of transactions happening across multiple cloud environments, there’s no way a person—or even a team of people—can manually assign policies to each workload. Organizations need a way to deliver zero-trust application segmentation in a scalable, transparent and automatic fashion. 

    A Connectivity and Security Platform 

    The way to do this is through the use of a modern application connectivity and security platform. Through a service mesh, an attribute-based access control (ABAC) model consolidates multiple third-party tools that provide visibility and security across application platforms and multi-cloud environments. This single view operational model gives application teams the ability to seamlessly and simply orchestrate security services across multi-cloud environments, automatically and at scale. 

    Unfortunately, granular policy management through microsegmentation increases complexity, which is the enemy of security. Suddenly, an organization may find itself with thousands of policies that dictate how different workloads access and interact with entities inside the network. These policies need to be continually updated and maintained, creating massive headaches for both application and security teams.

    When a workload is deployed, the associated policies are created along with it and move through the environment with the workload until the workload reaches the end of its life and is decommissioned. As applications run over time, they are being characterized by their unique behavior. This runtime security characterization allows policies to be automatically selected and applied directly to the workload.

     However, for a service mesh to work and enable secure applications in a multi-cloud environment, it needs to follow zero-trust principles without adding complexity and without slowing down the agile delivery cycle. Here’s how you do that:

    1. Baselining trust: A modern app connectivity and security platform should have native observability and self-discovery capabilities, such as being able to automatically discover APIs, catalog APIs and generate API documentation based on the OpenAPI standard. The modern app connectivity and security platform should be able to continuously baseline application behavior and detect anomalous application behaviors. This needs to alert on unknown and zero-day attacks, especially exfiltration of sensitive data.
    2. Establishing trust: It is critical to define the interconnectivity needs of different pieces of the application right off the bat. This explicit declaration of intent is typically done manually by application teams during the deployment of the application as part of a CI/CD pipeline. Another option is to automatically discover the connectivity intent during the testing phase of the application and allowing the service mesh to identify and record the resulting communication flows between microservices’ APIs. These are the basis of the application’s segmentation policies.
    3. Enforcing trust: There also must be a mechanism to automatically apply the appropriate application segmentation policies to enable the necessary communication for the application to run as intended. In the microservices model, different pieces of the application are spun up and down dynamically to enable the application to run as intended. It’s critical that the application segmentation policies that govern accessibility also adapt to these changes. This is done through the service mesh control plane that interacts with the application platform to gather the inventory of workloads.
    4. Dynamically adjust trust: As the applications run over time and clients interact with them, they are being characterized by a behavior. In this case, a security behavior. Observing this behavior can be accomplished through various runtime analysis tools that organizations already have in place that detect process, container, network and user behavior to provide security context. However, to maintain trust, there needs to be a way to integrate these tools through the service mesh to create a single source of truth. 
    5. Extending the trust model to the edge: Applications also interact with software-as-a-service (SaaS) platforms such as Salesforce or SAP, and other apps outside the data center. Ideally, the service mesh/zero-trust application segmentation model can integrate with other security solutions in the cloud such as secure access service edge (SASE), secure web gateway (SWG), cloud access security broker (CASB) and other zero-trust security components. This standardizes the processes for establishing trust across the data center, multiple cloud service providers, SaaS platforms and web apps—ensuring consistent security and compliance posture across the entire organization.

    Modern applications are transforming how business works by enabling agility and real-time decision making, but they will never reach their full potential unless application teams work with security teams to protect users, data and applications in multi-cloud environments. It’s clear that organizations need an evolved security model that application teams can use to seamlessly establish trust and orchestrate application segmentation across multi-cloud, multi-platform environments. Service meshes can provide the visibility and control needed to establish and continually evaluate trust.

  • Multi-Cloud Is Not About Lift and Shift

    Multi-Cloud Is Not About Lift and Shift

    Multi-cloud is often framed from the perspective of “lift and shift.” In other words, an organization takes a computing environment previously running on one cloud and transfers it over to a different service provider. Cloud migration may make sense for cost savings or performance benefits and such a shift may be necessary when migrating on-premises data centers to a public cloud.

    In theory, lift and shift sounds like it would empower cloud consumers with more choice in the marketplace. However, according to John Gentry, CTO of Virtana, lift and shift is quite rare in practice; it may not be the true driver behind multi-cloud strategies. Moving resources between clouds can result in costly egress fees. Plus, culturally-ingrained cloud preferences become challenging to shake. Unique configurations and add-on software-as-a-service (SaaS) make each cloud more nuanced, requiring new skills and procedures with every migration.

    Instead, Gentry advocates for a “fit-for-purpose cloud” strategy. This attitude is less about moving similar workloads between clouds but, instead, pairing particular types of workloads with the appropriate cloud types. According to Gentry, using multiple clouds simultaneously could still help organizations strategically align their digital resources and reduce dependency on a single cloud service provider (CSP). But, the real value of a hybrid multi-cloud setup lies in matching computing environments to different business layers.

    Fit-For-Purpose Cloud

    At first glance, the ability to move between clouds appears to be driving a new multi-cloud economy where cloud strategists can swiftly migrate resources and optimize intercloud utilization. However, when organizations attempt to shift, they usually experience many hidden costs, Gentry warned. These often pop up around data egress. Or, new data storage costs may take a surprising toll, Gentry added. “A lot of companies look at it from a computing perspective and they don’t account for the storage footprint.”

    DevOps in the cloud also introduces new responsibilities and processes that may differ between clouds, continued Gentry. From unique storage operations to managing the life cycle of a virtual machine, each cloud carries unique configuration methods. This makes it more difficult to abandon established procedures in favor of a different computing arrangement.

    Nevertheless, Gentry recognizes that we’re starting to see a maturing effect of the multi-cloud concept, especially among large enterprises. “Companies have a multi-cloud strategy—it’s less about moving between clouds than about picking a cloud that has specific advantages for a given workload,” he said. In a fit-for-purpose cloud approach, different workloads correspond to different layers of the business. For example, an organization may require a local data center or private cloud for high-security data. Certain applications may benefit from a distributed global public cloud, whereas other workloads could reap performance benefits and cost savings from a cloud-adjacent edge model. “These specific areas may not have anything to do with one another other than supporting the overall business,” explained Gentry.

    Matching Cloud Types to Business Units

    So how do we match the workload at hand to the ideal computing arrangement? Gentry identified three emerging cloud types:

    • Private cloud: A private core for particular functions that can’t be replatformed or rearchitected. Business areas such as financial records or patient care hold sensitive data that must be stored properly to meet regulations and SLAs.
    • Public cloud: End customer-facing, where sensitive data is not an issue. Public distributed cloud is ideal for delivering a highly available front end for customer-facing digital experiences.
    • Cloud adjacent/edge: When an environment is kept in a cloud adjacent facility with relatively local geographies. This may sit alongside the public cloud or connect to a front end in a cloud.

    For example, Gentry described how a large health care company uses a hybrid multi-cloud setup to support various business divisions. The organization is keeping traditional patient care workloads exclusively on-premises; due to regulatory reasons, it will never see the inside of a cloud. Yet, they are simultaneously building the next generation of applications in a public cloud, using Google Cloud to scale a clinical trial division. Simultaneously they began using Microsoft Azure for their back office. This scenario highlights one peculiar advantage of late-stage cloud adoption, noted Gentry: “They had the advantage of being able to take a more thoughtful approach.”

    Gentry described another case of an organization performing genomic sequencing. For data-heavy applications like this, where there is a high dependency on input and output, syncing with a public cloud could be extremely costly and introduce latency. For them, the most cost-effective method was to use a cloud-adjacent or edge model alongside a public cloud.

    How to Leverage Fit-For-Purpose Cloud

    One situation that may warrant cloud migration is a complete replatforming, noted Gentry. He described one early cloud adopter that rushed into AWS, only to find it wasn’t cost-effective for their needs. Architects then had to make tough decisions to determine what would be repatriated back to local data centers and what should remain in the cloud. “Their only motive going from cloud to cloud was, ‘We made a bad choice and we want to move.’”

    Clearly, to match cloud use with business requirements, you must choose the appropriate cloud. AWS is widely adopted for elastic computing and offers a wide product catalog. GCP is offering feature innovation and cost reduction to compete and is going after un- and under-penetrated regions. Azure, on the other hand, will offer licensing advantages if you are a Microsoft shop.

    Secondly, to unite IT around a hybrid multi-cloud strategy, you must remove the adversarial state between traditional ops and cloud ops. Classic ops is typically very safety-oriented, using a slow approach with endless tests in pre-production. Traditional ops may produce yearly updates. This is directly opposed to the new cloud ops approach, which emphasizes agility, speed and constant deployment. “They sit in different silos,” Gentry explained.

    To solve this dilemma, companies must share technical skillsets between the three main cloud types. “DevOps must become a continuum for all types,” Gentry said. In addition to cultural change, DevOps tools must evolve to monitor workloads across a hybrid multi-cloud estate. This will require integration to tie together tools and deeper observability.

  • How to Know if You Need Multi-Cloud — and Succeed if You Do

    How to Know if You Need Multi-Cloud — and Succeed if You Do

    There are many good reasons for running in multiple clouds, as well as times when multi-cloud environments are unavoidable due to organizational history or legal reasons. However, operating in multiple clouds adds complexity, increases operational overhead and can become expensive. Organizations should only pursue it when they have clear business reasons for doing so.

    In this article, I’m going to cover some common situations when organizations can get value out of multi-cloud as well as strategies for success. Because multi-cloud is hard, the first question organizations should ask themselves is, “Do we really need multi-cloud?” So, the first order of business is to outline when technology leaders are better off avoiding multi-cloud altogether.

    When Multi-Cloud is a Bad Idea

    A single application and its data should never span multiple clouds, if it can be avoided. Here are some common reasons organizations adopt a multi-cloud approach when they would be better off avoiding it.

    Short-term bursting (in hybrid cases). “I’ll just tap into a public cloud if my private cloud suddenly needs extra capacity.”

    Disaster recovery. “Let’s run this application on AWS and Google in case one of them disappears overnight.”

    Staying cloud-agnostic. “By running on multiple clouds, we are no longer locked in.”

    In all the cases above, network latency and egress cost will hurt your application and your business. In the best-case scenario, you will spend a lot of time and effort prematurely optimizing for unlikely scenarios.

    Unless you’re perfectly prepared, please, don’t go there.

    When Multi-Cloud is a Necessary Evil

    There are also plenty of times when multi-cloud is a drag on the engineering organization and a drag on the business — but can’t be avoided. Here are totally legitimate reasons to have a multi-cloud setup that will still require more effort to maintain than operating in a single cloud.

    Mergers and acquisitions. Some organizations can end up operating in public clouds and private clouds as they acquire other companies. The effort required to migrate everything to one cloud provider often isn’t worth it, so everyone continues using the same cloud they used pre-acquisition.

    Legal. Depending on the type of data you gather and the jurisdictions you operate in, you may have to worry about where your cloud provider has regions available. There will be times when you need a data center in multiple jurisdictions; none of the cloud providers are in all of them. In those cases, you don’t have much choice, you need to be multi-cloud.

    If you need to use multiple cloud providers, either for legal reasons or because of mergers, it’s best to focus on making multi-cloud management as painless as possible — while still accepting that it will not be as smooth an experience as running all workloads in a single cloud.

    When Multi-Cloud is a Solid Strategic Move

    There are also some very good reasons to adopt a multi-cloud approach on purpose. For example:

    Facilitating engineering speed. Engineering speed is paramount. Companies who focus on using multi-cloud to become cloud-agnostic and avoid lock-in often sacrifice development velocity, but if the organization instead uses multi-cloud to allow everyone on the team to use the tools and environment they are most comfortable with, it can increase velocity.

    Best-of-breed tooling. The cloud providers’ offerings are not totally identical. Multi-cloud can let organizations use the best tools from each cloud provider; for example, machine learning technology from Google, compute from AWS and business intelligence from Azure.

    Better customer experience. Especially if latency is a big concern, a multi-cloud approach can help organizations get physically closer to users, providing a better customer experience.

    There is a common thread here: When evaluating whether or not you have a legitimate need for multi-cloud, the key question is whether you will be fulfilling a psychological need, a theoretical need (in other words, something that you do not actually need at this moment but might at some future date) or a concrete legal or technical need that you can easily describe. If there are no concrete legal, technical or business reasons for pursuing multi-cloud, don’t. There are costs to pursuing multi-cloud, so organizations that won’t actually reap benefits from it shouldn’t attempt it.

    How to Succeed

    Multi-cloud is hard. Here’s how to increase your chances of success so you can get the business benefits of better tooling or better customer experiences from your multi-cloud deployments.

    Use a cloud management platform. Getting a single pane of glass for all your deployments is critical to managing multiple clouds without pulling your hair out. This abstraction, however, comes at the cost of supporting very deep and cloud provider-specific use cases, for example, using obscure service X.

    Standardize workflows with Terraform and Ansible. You need to have processes that are as repeatable and predictable as possible. Even with standardized workflows, you still have to adjust for each environment, but the more standardization the better.

    Use Kubernetes. Kubernetes lets you abstract the infrastructure layer and move workloads around more easily, even across clouds. The caveat here is that you have to adopt microservices and deal with the increased complexity of managing Kubernetes and its underlying infrastructure.

    Each of the above approaches has its merits and flaws. They are not mutually exclusive, and you should not treat them like they are. Be prepared to mix and match depending on your needs.

    Weigh the Costs and Benefits

    Sometimes companies are not realistic about their technical capacity or what their needs are. They want the ability to do the latest thing they read about without thinking about whether or not that technology or approach will provide business benefits.

    Multi-cloud adds a huge amount of complexity to your deployment. If multi-cloud truly is essential, however, use tools and platforms that hide that complexity from users and can simplify the management process.

  • From ‘Cloud Zombies’ to Multi-Cloud Experts

    From ‘Cloud Zombies’ to Multi-Cloud Experts

    A significant risk associated with cloud migration is overspending. For years, zombie-like obedience to AWS has resulted in price lock and escalating fees at many organizations – this is a tale for fighting the cloud zombies.

    Cloud costs around data egress or application bandwidth are often not transparent and thus highly unpredictable. Complicating this problem is the need to rapidly develop and scale large application ecosystems, leading to snap judgments by project engineers to buy tools. Or, cloud purchasing decisions fall to the CFO, who may not be qualified to understand technical nuances. Without cloud spending forethought, it’s easy to enter unsavory pricing commitments.

    However, all of this is changing. As cloud service providers (CSPs) mature their offerings, competitors have risen to take on AWS, unlocking more consumer choice throughout the cloud landscape. In a multi-cloud world, cloud economists are leveraging lift and shift capabilities to optimize performances. Ironically, companies are also seeing cost benefits in retaining some on-premises servers.

    I recently spoke with Scott Leatherman, chief transformation officer at Virtana, to get his take on preventing cloud cost escalation and how IT should streamline multi-cloud environments to stem the cloud budget.

    Zombies in the Cloud

    When the cloud arrived, it promised high performance at a low cost. Companies were happy to offload on-premises servers for the ease of cloud arrangements. For years, there was a “zombie-like loyalty” to cloud platforms, said Leatherman.

    Not much was thought about costs rising in parallel with the astronomical growth of the web, mobile and IoT. Executives penned long-term pricing contracts without a second thought. Then eventually, reality hit. And it came with a hefty price tag.

    Spooky Cloud Expenses

    As cloud-enabled businesses took off, they encountered many hidden fees. To name a few:

    • Egress: Fees for moving data in and out of the cloud.
    • Application: Fees for moving applications to new instances.
    • Workloads: Mounting costs for increasing bandwidth and workloads.

    These and other add-ons could quickly raise a cloud bill from $200 to $200,0000 a month. Complicating this was the fact that many large organizations purchased multi-year cloud subscriptions locked at a specific price.

    Counterintuitively, such cost-savings guarantees are “completely backward,” Leatherman said. As computing power increases exponentially per Moore’s Law, servers become cheaper to maintain.

    “You’ve literally committed yourself to something that is depreciating in cost,” he said. Yet, those savings don’t trickle down to consumers and SLAs have remained pretty flat. “What’s the most frustrating thing for me is that the best way to run this business is to lock people in.”

    The Zombies Become Aware

    In the wake of COVID-spurred digital transformation, cloud zombies are waking up to slash the budget, finding cost-effectiveness in multi-cloud strategies. Some companies are even reaffirming ties with on-premises servers.

    If performance isn’t worth the cost, it defeats the benefits of moving to the cloud entirely. So, how can we smartly optimize our environments for quality performance with leaner financial margins? Leatherman shared some steps to become cloud-smart:

    1. Baseline Your Footprint

    The first step toward reducing cloud costs is maintaining a baseline of all cloud dependencies and private data centers. This should cover a deep cost and performance analysis.

    “You need a baseline in your data center—what can I move? what should I move?” said Leatherman. Unless you have a baseline of what your data center is doing (both private and public), you can never understand what resources should move to the cloud. Powerful apps for monitoring the public cloud could help audit architecture.

    2. Optimize, Optimize, Optimize

    Only after mapping topologies can you can begin to optimize performance. Since usage differs depending on the season, cloud optimization should respond to yearlong application usage trends. For example, ERP software may pull significantly more requests at the end of the quarter and e-commerce spikes during the holidays.

    Organizations should ensure the elastic cloud truly scales to application needs, but only when needed. Ensure systems of orchestration and routing function properly, and diligently search for hidden fees. “The cost that sneaks up on you in the elastic cloud always comes up,” said Leatherman.

    Heavy computation processes, such as machine learning over big data, will require enormous server consumption. For resource-intensive scenarios, Leatherman recommended keeping code lean. Whereas CPU relies on the laws of physics, “application developers are only limited by creativity,” he said.

    Application developers should whenever possible optimize code to avoid redundancies. Doing so yields a positive environmental impact, too—eliminating operational inefficiencies can decrease cloud server usage, which reduces carbon footprint.

    3. Lift and Shift

    GCP, Azure, Oracle and other CSPs mature, the zombie-like loyalty to AWS is fading. “Now that there is parity across cloud vendors, things are changing,” he noted. “The flexibility in the marketplace is really dynamic.”

    In a multi-cloud world, organizations can leverage a hybrid cloud and “lift and shift” toward the best cost optimizations for their specific needs. This is where maintaining a strong baseline will help continually test cost efficiencies among cloud competitors.

    4. Refine Your Tool Procurement Process

    Another solution involves scrutinizing your cloud procurement process and the personnel involved. As mentioned above, new cloud tooling purchasing may occur at the DevOps level or large contracts may be escalated to the CFO office.

    Unfortunately, neither side is in an ideal situation to make smart financial decisions—one faces an urgency to deliver and the other can’t see the trees from the forest (and especially not the termites eating the valuable wood). Many believe a new role is required—The Other CFO—to help optimize the cloud stack.

    5. Retain and Optimize Private Data Centers

    By now, most enterprises are accustomed to having both a data center and a cloud center team. Leatherman argued that ultimately these two teams must work together to avoid outages and reduce the exponential costs of moving to the cloud.

    From a security perspective, there are still significant advantages to maintaining on-premises private clouds and data centers. By leveraging private assets, you aid data protection efforts and have increased control. “Datacenters have value,” he said. “Unless you started there, no one will be 100% cloud.”

    Although cloud migration seems inevitable, through software automation and Moore’s law there is value in on-premises. As a result, Leatherman predicts a rise in private cloud data center optimization and management services by third parties.

    6. AI for Cloud Cost Awareness: DevFinOps

    Finally, AI soon may be available to automatically scan for cloud cost impacts before applications are even deployed.

    Most DevOps teams use container security scanning or automated compliance validation as part of their DevSecOps process. Leatherman suggests future DevOps tooling will similarly evolve to display automated notices that estimate cloud costs for your actions in real-time.

    For example, as engineers are pushing code, a popup could display server utilizations and a cost impact breakdown. Or, inline code validation suggestions could find redundancy to decrease waste. Perhaps we’ll need a new abbreviation for this Developer + Finance + Operation focus—DevFinOps, anyone?

    Such an AI would likely not negate the need for a cloud economist to help manage multi-cloud complexity. “We’ll still need them,” said Leatherman.

    Surprises in a Multi-Cloud World

    COVID–19 is accelerating deployments tagged for much shorter timeframes, forcing many more instances to public clouds. Businesses need to get performance up and meet their SLAs. To reduce expenditures, they must quickly lift and shift to the most performant and cost-efficient environments.

    The gravity is apparent, yet hasty moves now could be disastrous for security and data privacy in the future. Besides rising cloud costs, there are other risks associated with the cloud that increase exponentially with multi-cloud environments. “It’s not just the financial spend, but the security and risk that goes along with it,” Leatherman said. “It becomes really scary how many people have access.”

    Not only must cloud spending decisions shift left, but security must arise earlier in the development cycle as well. Compliance with regulations such as GDPR or HIPPA should also influence how teams manage data between clouds.

    The Cloud is Relatively New

    An IBM-endorsed study found enterprises are only 20% of the way through their cloud journey. Many enterprises are still just at the beginning of their cloud transformations, and 90% plan to expand their cloud footprint in the next year.

    The cloud journey is quite long, and many have quite a way to go. Knowing this, cloud economics will only rise in importance. As I recently covered, cloud expertise is now superior to a university degree.

    Current forces, like the COVID–19 crisis, will no doubt continue to “drive people to the cloud,” said Leatherman. While responding to the imperative to deliver more and higher speeds, it’s essential to be smart, leverage existing assets, and optimize cloud usage at every level possible. “It shouldn’t just be cloud-first,” he said. “It should be cloud-smart.”

  • Multi-Cloud Cost Optimization For The Enterprise

    Multi-Cloud Cost Optimization For The Enterprise

    Multi-cloud is an increasingly popular approach for deploying enterprise computing assets. But, in the same vein, managing cloud costs has become a huge challenge. Whilst public cloud continues to grow in popularity, there are many factors that can increase a cloud bill that needs to be taken into consideration. A smart cloud cost management strategy certainly helps to avoid any unwanted billing surprises. Enterprises progressing through their cloud adoption need one in place to control their spend.

    The benefits of cloud infrastructure—scalability, control, security, etc.—are easily seen, but there are challenges, too. Perhaps the biggest challenge of cloud cost management is the difficulty that organizations have in tracking and forecasting usage— these uncertain budget costs can be a massive cloud management pain point. The ability to scale up and down on demand has allowed resource procurement to transition from sole ownership of the finance or procurement team to stakeholders across IT, DevOps and others. Procurement is now in the hands of a group of cost-conscious stakeholders who are responsible for understanding, managing and optimizing costs.

    How much will the public cloud cost? You should begin your cloud cost management strategy by looking at the public cloud providers’ billing models—just like any other IT service, the public cloud can introduce unexpected charges. How much storage, CPU and memory do your applications require currently? Which cloud instances would meet those requirements?

    Then, it’s a question of estimating how much those applications would cost in the cloud and comparing these figures to how much it currently costs you to run them on-premise. If you plan to use multiple public cloud providers, integration and other factors can lead to unexpected fees—try and plan application deployments to see where you might be liable for extra costs. 

    Initially, it seems that most vendors offer similar packages and prices—when you examine them in detail however, perhaps one vendor has a much lower price for certain types of workloads. Understand your business requirements before committing to a cloud vendor, and avoid vendor lock-in. Moving workloads from one cloud vendor to another can sometimes be difficult. If you don’t do your due diligence here, it can be subsequently too difficult to migrate applications or workloads after they are in production.

    Confronting Cloud Costs

    You must first identify waste by uncovering inefficient use of cloud resources. Cloud cost management is not a one-and-done process, but you can make a start saving money on your cloud infrastructure costs if you address key areas that account for the majority of wasted cloud spend and budget overruns.

    Visibility

    Ensure teams have the direct ability to see what they are spending. It’s easy to get carried away spinning up services, unless you know exactly what you are already spending. Identify what you have, and who owns it. Tag resources with user ownership, cost center information, product name and others to give you a better handle on where the spend originates. This information can be used to track usage through detailed billing reports.

    Budgeting

    Once you have a handle on what your spend is, set budgets per account. Doing this after establishing a baseline ensures that you are setting practical and realistic budgets that are based on the actual usage. Look to whitelist instance types (RDS & EC2) to only allow instances of specific types, classes or sizes.

    Manage Storage Lifecycle

    Ensure that you are rotating logs and snapshots regularly and backup and remove any storage volumes that are no longer in use. Ensure that you are using only one logging configuration and have added additional ones only when absolutely necessary. Also, ensure that sandbox or trial accounts are only utilized for exploration purposes and for the duration committed.

    Use Containers

    Another technological solution that can help to reduce operating expenses is the use of containers. Often used by IT teams taking DevOps approaches, containers package applications together with all their dependencies, making them easier to deploy, manage and/or migrate from one environment to another. Containers can also be more cost-effective on one hand but can cause more complexity, and therefore increase costs, if built in the wrong way.

    Review Regions

    Prevent staff from provisioning unapproved virtual instances from the marketplace that include software license costs, or from using specific OS or DB engines from vendors with whom you do not have enterprise agreements in place or are too costly to run at scale. Review in which regions you have services running. The cost of services per region can vary as much as 60%. You need to ensure you are balancing the need with running services in a given region with the cost of doing so. You can use instance scheduling to start and stop instances on a planned schedule. Shutting down environments on nights and weekends can help save you 70% of runtime costs. Look to determine which environments need 24/7 availability, and schedule the rest.

    Use a Cloud Cost Management Vendor

    Many organizations decide that tackling these cost optimization chores on their own takes too much time and skill. Instead, they leverage services from reputable cloud cost management vendors. Cloud cost management is one of the major pain points organizations confront when migrating to the cloud—cloud costs are difficult to estimate without some kind of assistance, due to the complexity of cloud infrastructure.

  • Overcoming Hybrid and Multi-Cloud Management Challenges with APM

    Overcoming Hybrid and Multi-Cloud Management Challenges with APM

    When companies move toward hybrid and multi-cloud, both leadership and IT can struggle to adapt their organizational structures and processes to a new, more complex way of doing things.

    With the classic form of DevOps, for example, operational monitoring and management procedures are radically new and different: from a management perspective, it almost appears as a free-for-all, making assessment and accountability to the business difficult to achieve on a regular, ongoing basis.

    The older system was straightforward: on-premises monitoring and management teams were organized around a technology stack, with associated monitoring and management tooling. The network, server and storage teams each had distinct processes. Different problems were escalated and triaged (Level One, Level Two, Level Three). It was formulaic—perhaps even annoying to some tech pros—but it worked.

    DevOps is different. Applications are changed, tested and deployed in production continuously, often on an hourly basis (or more frequently). It’s revolutionary because it delivers maximum business market agility, embraces technical and business evolution, and is never-ending. It radically redefines the concepts and approaches we associate with application and infrastructure support and triage processes.

    But there’s good news: Application performance solutions and workarounds are coalescing. Here’s a few ways we’re seeing teams evolve to overcome the challenge of hybrid and multi-cloud application and infrastructure management.

    Try a Monitoring Engineer

    Right now, we’re all experimenting—we’re in a digital Wild West. In that spirit, forward-looking outfits are working with the concept of a monitoring engineer (sometimes monitoring support), someone who owns the monitoring of everything important in the context of an application or a line of business.

    “Monitoring engineer” as a job title can mean many things. If you Google it you’ll find open positions for many kinds of these engineers. But for our purposes, it’s a stand-in for a new concept, a new way of thinking. To be clear, this isn’t a network monitoring engineer, or any other kind of job with the title of engineer. It’s a new way to better and more proactively align IT with the business goals of the company paying the bills.

    Traditionally, metrics have been aligned to the application or applications being built out—not the business itself. More importantly, these metrics aligned around answering questions like, “Is this specific element of infrastructure or application available and performing?” Especially at the infrastructure level, performance was defined typically as a technology resource utilization metric (i.e., how efficiently are technology resources being consumed). This new concept of monitoring engineer is designed to allow management to quickly get the answers it needs in a consolidated and focused fashion—to move, in effect, from resource-centric monitoring to service and application-centric monitoring.

    Application performance monitoring (APM) has evolved thanks to measurement focused on application availability and performance rather than infrastructure. APM requires a certain amount of applications knowledge. The monitoring engineer needs to know enough about the application environment, how the application is configured and how it’s deployed operationally but doesn’t have to be the expert in the application code itself.

    Importantly, a successful monitoring engineer requires time and focus—and management needs to set up a structure to support it. Any competent system administrator or network engineer who’s worked in a complex private cloud or on-prem hybrid environment would have the skills to do this. But these engineers need time and the ability to focus on their job, while adding APM skills to their repertoire.

    Creating Metrics That Matter

    Along with the dedicated monitoring engineer who’s minding the technology store for management, processes and languages must be standardized.

    Think back to when virtualization swept the tech pro world, some 10 or 15 years ago. We had to change and adjust. We have to do it again.

    We should start by standardizing the application languages tech pros use. How we choose languages should always be business-driven: Different languages are good at different things, which should be the deciding factor. The number of languages should also be limited, so management can be more straightforward. Similarly, standardization should be the default wherever possible to approaches considered for automated deployment and dynamic configuration management of both applications and infrastructure resources.

    Keeping things as simple as possible doesn’t mean not learning new things, however. Management will need to cultivate a culture of curiosity. Tech pros must learn new ways of working—if they don’t, the transfer to hybrid and multi-cloud will be a guaranteed slog, or worse.

    If the tech pros stay curious, they’ll stay ahead. The APM market is growing at a considerable rate, and the people with the curiosity to get involved in it are the ones who will succeed.

    APM gives tech pros a powerful tool they can easily add to their skillset by which they can then generate the data and the metrics in the language of the business. When metrics are business focused, they matter.

    The measurements the business (and customers) care about are fundamentally limited to four key metrics, in two classes:

    • Application performance—how much business work is being accomplished over time, along with the response-time experience of users.
    • Availability management—whether all resources associated with the entire technology stack are continuously up and available to service the applications, along with any and all associated errors.

    Taking this approach to measurement is about meeting the company needs in business terms, not IT. This approach is critical for ensuring excellent customer experience or an ability to immediately and cost-effectively respond to peaks in business demand. This approach answers the questions: What are users experiencing? How are specific pages and transactions performing? APM can also discover what infrastructure components are needed to support those applications delivering successful service.

    Answers like these can’t be discovered with infrastructure monitoring alone, nor with infrastructure-centric monitoring of application performance that infers performance from technology resource utilization rates. Nor can they be answered with network monitoring or storage monitoring. Only APM provides the answers the business needs. It’s the glue to bind together the different silos.

    Measurement Matters Most on a Thin Margin

    We’re in a new environment. In many ways, it’s the Wild West and there are many ways to win and lose. Few things seem absolutely right, except this: Tech pros need to be completely aligned with the businesses they work for.

    In the past, a strategy such as APM was perhaps better aligned with industry verticals. Companies operating with thin business margins were reluctant to measure. Now, it’s the opposite. Companies such as those in the e-commerce, B2B, B to high volume and B2C spaces continue to operate on thin margins and are now in a virtuous spiral. Their success depends on efficiency—and efficiency is key to making them win in the increasingly competitive marketplace.

    To achieve this level of success, companies must measure and assess where they’ve been and where they’re going. They need to do more than just keep up with the competition, they need to accept innovative processes such as DevOps, while continuously measuring their progress.

    Ultimately, speaking in the language of business can take many IT professionals outside their comfort zones. But APM gives the wary tech pros a powerful tool for generating the kinds of data and metrics management needs. APM grounds the business, but also makes sense of the new hybrid and multi-cloud environment. It’s a chance for management and IT to bridge the gap between us and them. It’s the best way to manage the changes to come.

  • Five Attributes of a Great DevOps Platform

    Five Attributes of a Great DevOps Platform

    As we move toward 2020, the expectations are high, the software industry is moving faster and the demand for rapid and continually improving digital experiences have raised the standard. To match the needs and demands of the market, firms around the world are embracing the DevOps culture to ensure and streamline the development, packaging, testing, deployment and maintenance of software at scale. 

    Every DevOps organization is defined by its own leadership, culture, practices, policies, leadership style, structure, talents, skills, technical capabilities, processes and tools. However, there are certain common characteristics that are important to consider before deciding a better DevOps platform to use in your organization. Today, we will discuss such important features that can help you while selecting your DevOps platform. 

    What is DevOps?

    DevOps is a mindset in an organization that enforces a set of collective practices to ensure easy collaboration between dev and ops so the business can run smoothly without any hassle. DevOps aims to fasten the time to market through frequent and incremental improvements to deliver quality software updates to customers. 

    The meaning and definitions of DevOps can vary from company to company. Automation being the focal point, firms want to focus on achieving zero-touch automation, with utmost security and governance as a priority in the delivery pipeline.

    Even though the meaning of DevOps varies, several inherent DevOps principles cannot be replaced, and they repeatedly insist on collaborative relationships, developing early, failing early, shared learning and continuous feedback. These DevOps principles enhance quality with improved deployment rates while simultaneously improving predictability, scalability and security of the production environment. Tech leaders in the company need to view DevOps as a holistic approach rather than a small set of guidelines for the teams, and DevOps guidelines should be aligned with the company’s long term technology vision and objectives. 

    Here are some facts to consider while deciding a better DevOps platform for your organization.

    A Mindset of a Unified Culture

    Culture plays a significant role in establishing the guidelines while embracing DevOps in any organization. Through DevOps culture, companies seek to bring dev and ops teams into harmony to promote collaboration, automation, process improvements, continuous iterative development and deployment methodologies. But above everything else, a sound DevOps culture fundamentally solves one of IT’s biggest people problems: bridging the gap between dev and ops teams to get them to stop working in silos and have common goals. 

    According to Gartner estimation, DevOps efforts fail 90% of the time when infrastructure and operations teams try to drive a DevOps initiative without nurturing a cultural shift in the first place. It is not just about the efficient tools or experts working; it is about the behavioral modifications and mentality necessary to effect cultural change.

    Hence, it is important for the firms to consider the culture of the company before selecting its tool as a potential DevOps tool for their development. 

    Automation Inside and Outside

    Automation is one of the key principles of a strong DevOps team because it has such a high return on investment. 

    Automation makes up as a large part of DevOps culture to standardize production platforms, and even firms believe it as true because standardization and automation help make deployments more predictable, easy and less prone to human errors. 

    Automate everything as part of the workflow process, including infrastructures, compliance and continuous delivery pipeline. For example, tools such as Artifactory can manage and control all your binary repositories to help your developers and ops collaborate and automate build and deploy tasks easily. Similarly, Docker allows development teams to containerize applications and automate application deployments with speed.

    By reducing manual, non-important and repetitive tasks, you will increase your development and testing speed while cutting down on human and unnecessary errors. Additionally, by automating tedious and repetitive tasks, firms free up team members to work on higher-level and more important tasks.

    Important to note here, JFrog Pipelines is an innovative DevOps automation solution that well integrates and connects all critical processes in the software delivery lifecycle in the company, from development to testing to production. Using minimum code, it allows you to create smart and event-driven workflows across tools and teams easily, to speed up the release of software applications. This helps you achieve continuous integration, continuous delivery, continuous deployment and continuous monitoring in DevOps.

    Support Both Hybrid and Multi-Cloud

    What is Multi-cloud?

    Multi-cloud is the use of cloud computing from two or more public cloud providers in single network architecture to meet their business objectives. A multi-cloud strategy has many advantages. It avoids vendor lock-in, decreases latency, enhances business continuity, overhead cost reduction and maximizes flexibility for development teams. However, multi-cloud management comes with some challenges that require careful orchestration, and needs to pay close attention to security and governance issues.

    What is Hybrid-cloud?

    A hybrid cloud is a mixture of on-premises and off-premises IT resources. Based on business and compliance requirements, the hybrid cloud allows firms to move data and applications between private and public environments. 

    Hybrid cloud computing allows instant transfer of information between public and private environments, allowing enterprises to experience the benefits of both environments efficiently. 

    Flexibility, scalability and cost savings are some of the top benefits of hybrid-cloud. 

    Considering a platform that supports both multi-cloud and hybrid-cloud is the best solution for the enterprises moving toward the digital transformation ladder.

    Continuous Updates 

    Frequently rolling out updates, in a continuous sequence, to bring service improvements to consumer devices more rapidly and efficiently is what every firm is trying to do these days. The customer wants new features as early as possible and continuously. That is one reason why companies embrace automation and follow practices like continuous integration, continuous deployment and continuous delivery through tools such as GitHub, Artifactory, Circle CI, Docker, Kubernetes, etc. 

    The DevOps platform should be able to manage your DevOps pipeline from a single pane of glass. A platform that can provide a universal end-to-end solution that integrates with your ecosystem to orchestrate and optimize all critical processes in your CI/CD pipeline. Boosting fearless updates continuously from code to the edge in self-managed, on-prem, hybrid and multi-cloud environments.

    A Robust Community 

    All successful companies have built their own communities through their products and services. DevOps is all about the culture shift. Changing existing culture and moving forward is one of the hardest things to do—despite the benefits that DevOps offers, such as speed and agility. No matter what changes a team implements, embracing DevOps often comes to a halt once the companies realize it requires a change in culture and mentality of all the teams involved. This is where the value of community comes in, by fostering the development of a more open communication, easy and supportive feedback, and collaborative culture within teams, companies can be able to drive this DevOps culture. This mindset should come from within and outside of the organization by tapping into this sense of community-based collaboration. Communities are required because they ensure the well being of many of the technologies we use daily.

    Your favorite DevOps platforms—Jenkins, Docker, Kubernetes, Artifactory—and their popularity is because of the communities they have created around the tools. 

    A well-focused DevOps platform gives power to people who listen carefully to what the market is saying, gets the feedback and utilizes it effectively. Hence, community is a very important feature of a DevOps organization. 

    Conclusion

    Companies around the world are embracing DevOps, and the demand for DevOps skills soars as organizations spend their time and money on digital transformation. DevOps has become a modern approach to IT that helps companies to think and execute broader business strategies. DevOps can drive significant brand value by accelerating speed to market, better collaboration, ensuring better testing and automation. A DevOps platform should have all the qualities mentioned above to succeed in this highly competitive market.