devopsy.kinsta.cloud

Tag: Multi-cloud

  • Five Major Mistakes to Avoid in Enterprise Multi-Cloud Strategies

    Five Major Mistakes to Avoid in Enterprise Multi-Cloud Strategies

    Employing a multi-cloud strategy is not as straightforward as it seems for enterprises due to the huge amounts of data and applications involved. Hence, mistakes are common in multi-cloud implementations. What are these mistakes and what can enterprises do to avoid them?

    The Growth of the Multi-Cloud

    The multi-cloud is now a staple in most enterprise IT infrastructures. This is a result of companies having to ramp up their data access and management processes to scale with rapid market demand.

    A study by data analytics firm, Sumo Logic, showed that multi-cloud usage in enterprises grew 50% each year for the past few years. The market is also expected to hit close to $8 billion with an excellent CAGR of 32.1% from 2017 to 2024. 

    Figure 1: The share of cloud environments in enterprises. Source: Forbes.

    This accelerated growth is justified by several factors. For starters, multi-cloud environments save businesses from locking into one vendor for cloud solutions—a common issue enterprises face when dealing with providers. The great bang for the buck ROI and exceptional performance of multi-cloud implementations are also two major contributors to its success.

    The Impacts of Deploying Multi-Cloud Strategies the Wrong Way

    Any tech trend that grows as fast as multi-cloud will come with concerning downsides. Enterprises may not have the skills and resources needed to effectively work with multi-cloud. This can impact performance, increase costs, or worse, create security vulnerabilities that can cripple unprepared organizations.

    The average company uses 16 SaaS tools at one time. While SaaS applications have built-in security, organizations are still responsible for securing their environments, especially for dependencies. A vulnerability in one application can affect the entire ecosystem without adequate recovery measures in place.

    Nominet’s multi-cloud survey respondents said they faced at least one data breach in 2019—50% more than hybrid and single-cloud users. With data breach penalties reaching millions today, enterprises cannot afford to impact their already tight margins by paying unnecessary fines. This is why multi-cloud strategies need to be approached with extra caution.

    Below are the five major mistakes to avoid in enterprise multi-cloud strategies.

    Going Multi-Cloud Without the Required Competency

    Organizations used to single cloud deployments run the risk of failure if they work with the multi-cloud without the required competency. Experience working with SaaS applications is not enough to warrant complete multi-cloud shifts. Enterprises should at least have the right technical expertise, tools and technologies in place.

    Development teams will have to revamp their mentality to work efficiently in multi-cloud environments. Other important business units also need to be reworked to accommodate this change. In other words, your company must establish a multi-cloud-focused culture, not treat it as just another new piece of technology.

    Invest in training to get team members up to speed with necessary multi-cloud skills. It can be expensive, but the ROI generated from productive employees far outweighs the cost of training. Your recruitment process should also prioritize candidates with proven experience in the field to make onboarding easier.

    Work with industry-standard tools to ease development in areas like pipeline automation, CI/CD and monitoring. This reduces the burden of QA while also giving developers peace of mind when working with the multi-cloud due to reduced deployment anxiety. Ultimately, your team should be able to build, test, deploy and monitor code in the cloud with minimal friction.

    Not Addressing Cloud Sprawl

    Unless you’re locked in, you will be dealing with various providers and technology stacks in your multi-cloud. Your environment may be overloaded with unnecessary assets and dependencies, leading to cloud sprawl, which negatively impacts budgets and performance. 

    To overcome cloud sprawl, plan your cloud infrastructure meticulously with respect to organizational goals. Only integrate core applications that fit your requirements to a tee. Nice-to-haves eat up valuable resources and can be postponed for later when your multi-cloud is mature.

    Rightsize your environment to make planning easier. Rightsizing matches resource allocation to your multi-cloud workload. It’s often automated or offered as a service by cloud providers. Enterprises can cut as much as 40% of operating costs by rightsizing their infrastructure—a huge advantage in today’s fierce markets.

    Not Accounting for Complexity

    More assets in your environment means more complexity challenges. Scalability, security and resource optimization are the three key areas where enterprises need to pay close attention. Integration will be tough as well since not all providers offer seamless connections with other tools. 

    Consider working with popular cloud applications if this is the first time your organization has worked with multi-cloud. Bespoke solutions are best implemented in stable environments and when there is a real need.

    Another factor to consider is your infrastructure’s load balancing strategy. Which resources have higher priority and which can be sacrificed when demand peaks? Automation is a must-have for load balancing, especially if your environment consists of thousands of assets—as is common in enterprise systems.

    Other complexity factors to consider in your multi-cloud strategy are:

    • Compliance.
    • Asset and data visibility.
    • Cost management.
    • Performance.
    • System design.

    Paying Too Much for Unused and Underutilized Resources

    Multi-cloud is not as cost-effective as expected if you spend too much on unused and underutilized resources. Fifty-two percent of enterprise cloud resources barely reach their optimal usage while cloud waste hit an all-time high of $14 billion last year.

    Thankfully, cost optimization is achieved as a side effect of mitigating cloud sprawl and rightsizing. Doing these two things, combined with best practices such as streamlining unused EBS volumes and snapshots, will significantly reduce your costs.

    Poor Visibility

    The number of assets in the average multi-cloud environment requires total visibility for your team to navigate through it. Without visibility, developers will have their work disrupted by intricate dependencies and foreign configurations that ruin the productivity of your organization. This can also result in security breaches should a dependency be compromised—how can your team find the root of the problem if they can’t see architecture?

    Map out every asset and dependency with mapping tools. By improving visibility, you bolster the security of your multi-cloud while allowing developers to deploy code with confidence when they have a full overview of your ecosystem. Integrate mapping insights with your organization’s technical documentation to further improve results.

    Bolster Your Multi-Cloud Today

    The easiest way to generate optimal performance from your multi-cloud is to avoid common pitfalls as early as possible. With the tips mentioned above, you can improve scalability, cost and performance without succumbing to complexity challenges.

    — Soumik Sarkar

  • Multi-Cloud Adoption: Time to Rethink Your Identity and Access Management

    Multi-Cloud Adoption: Time to Rethink Your Identity and Access Management

    This may well be the decade that the data center’s reign falls, and multi-clouds prevail. A multi-cloud strategy, which incorporates cloud services from multiple vendors, promises plenty of benefits, including improved resilience and flexibility that makes it easier for enterprises to meet various application and data needs. But, there will also be operational challenges. Expect security, specifically identity and access management (IAM), to be one of them. 

    Gartner states that “by 2025, 80% of enterprises will have shut down their traditional data center, versus 10% today.” Except for a few mission-critical processes that will remain on-premises because they require intense oversight and control, much of an enterprise’s workloads and data will be spread across a multi-cloud environment, with users accessing applications from a range of devices from multiple locations–making it more difficult to secure, control, track and manage access to applications and services. Without a comprehensive IAM plan, an organization could be more vulnerable to attacks and data breaches.

    Instituting the right IAM strategy now, in concert with an evolving multi-cloud architecture, will help protect threats and ensure that the right users have access to the right information when they need it. To get started, we recommend following these key recommendations. 

    Get Your ID Store in Order

    IAM solutions are designed to make sure only people appropriately identified and cleared can access an enterprise’s systems and services. In today’s increasingly complex IT environment, an IAM solution must include an ID store that supports both on-premise systems and cloud services. Unfortunately, too many companies still rely on Microsoft Active Directory as the single source of truth for the IT services they provide. This needs to change.

    As companies begin to adopt multi-cloud architectures, they’ll soon discover that Active Directories are not flexible enough to support IAM, nor can they keep up with the growing number of potential threats. Integrating an identity software product that can manage users’ digital identities, credentials and groupings with Active Directory may work as temporary solution, but as user passwords and access rights are dispersed across on-premise and cloud-based systems, things can get complicated quickly, taxing even the well-resourced IT team.

    If you haven’t already done so, it may be time to extend Active Directory (AD) to Azure Active Directory (Azure AD), Microsoft’s multi-tenant cloud-based directory and identity management service that enables Single Sign-On (SSO) access to on-premise and cloud applications, putting users through an authentication process to prove they are who they say they are. It uses multi-factor authentication, a two-step identity verification system that requires two or more of the following methods: something you know (password), something you have (trusted device) or something you are (biometric screening).

    Embrace Zero Trust

    The premise of zero trust has been around for several years. According to CSO, the first model was defined by John Kindervag (then principal analyst at Forrester Research Inc.) in 2010. The idea is that when it comes to securing enterprise systems and data, no user–internal or external–can be trusted. Security threats are much more sophisticated today and are impacting organizations at greater rates than ever before.

    Malware such as phishing, email phishing and drive-by downloads–which can occur when visiting a website, viewing an e-mail message or by clicking on a deceptive pop-up window–put an organization’s identity and authentication at increased risk. Once an attacker gets a working identity and authentication method, he or she can do almost anything, including system damage, data leaks and destruction, and more. A zero trust network that rethinks approaches to resource access is quickly becoming a necessity.

    Part of the move to zero trust should include a decision to move away from passwords, which are still widely used. Passwords are typically too weak or often re-used, making them vulnerable and difficult to manage. As such, they don’t deliver robust enough security for sensitive systems and confidential information. A passwordless approach eliminates this problem by removing the need for users to remember passwords and for organizations to store them. There are several ways to go passwordless, including adopting biometric authentication such as touch ID and face recognition, and token-based methods such as mobile app authenticators or secured USB keys.

    Control Your Multi-Cloud Strategy

    Of course, distributing an enterprise’s workloads and data across larger numbers of clouds operated by different providers and located in various geographic regions can increase the complexity of IAM. IT staff will have to learn how to manage, provision, control, track and synchronize the systems in each environment, and such a highly distributed operation can easily become an operational challenge. Things can get even more messy, and risky, if an enterprise’s multi-cloud adoption develops in an ad-hoc manner.

    Multi-cloud best practices include working with existing cloud partners, adopting orchestration tools, controlling the risks of shadow IT and keeping the number of cloud environments to a minimum by adding only those clouds that support and elevate an enterprise’s business goals.

    With multi-cloud adoption on the rise, IAM is becoming increasingly important in order to protect against insider and outsider cyber threats and to ensure that the only the appropriate users can access the resources they need, when they need them. 2020 is the year to get identity and authentication right. It’s time to develop a comprehensive IAM strategy that includes an advanced ID store, zero trust and controlled multi-cloud adoption.

    — Richard Diver

  • Six Routing Challenges When Managing Microservices in Production and How to Avoid Them

    Six Routing Challenges When Managing Microservices in Production and How to Avoid Them

    Even experienced DevOps teams can struggle with the nuances of managing microservices in production–where a greater spotlight on network communications can introduce new operational challenges beyond those common to traditional architectures. But, by being smart about your software-based routing components, it’s possible to avoid or reduce the impact of roadblocks in the following areas.

    Implementing Tracing and Monitoring

    Even applications that are rigorously tested during development will exhibit anomalies in production. To address these, DevOps teams require effective tracing and monitoring tools to gain visibility into what’s happening within clusters at runtime.

    As a strategy, developers should select routing solutions that integrate well with their existing monitoring and tracing backends. Remember that while a microservice may be developed by a certain internal team, once deployed it becomes available for others. If the application is instrumented to be traceable, compatible tracing tools can dynamically identify the source of service invocations and their call flows–enabling other teams to utilize the microservice. When the application is also designed to provide metrics, monitoring tools can usefully track the microservice’s key resource consumption metrics to assess the scalability of its subcomponents under load, and recognize any performance limitations that require attention.

    Because all inter-service communications travel through software routing elements, you can strategically design your application to enable microservices tracing and monitoring data to be collected. Teams can then put this data to work to more easily overcome challenges when building out new capabilities.

    Mitigating Communication Failures

    Considering the myriad communications taking place within production microservices-based environments, it only makes sense that this architecture will be prone to communication failures in which microservices simply cannot be reached. Whether these failures occur as the result of an error by the container, host, a network partition, or a short-term interruption in the availability of the service itself, resilient safeguards must be in place to mitigate any impact to an application’s user base. 

    For example: When an instance fails, the load balancer can be used to automatically reroute requests to healthy instances, and then return traffic to the failed instance upon detecting that it’s again available. In scenarios where an entire microservice becomes unavailable, client services should leverage circuit breaking to stop requests, return an error and initiate a fallback response. Doing so avoids dangerous repetition of retry requests, which only eat up resources and can lead to cascading failures.

    Each of these mitigation strategies could be accomplished by placing the necessary logic with each client. However, this technique would be both cumbersome to implement and prone to errors. The better approach to these challenges is to leverage routing solutions to perform instance health checks and circuit breaking, allowing DevOps teams to control how their applications respond to faults, rather than relying on logic at the network layer.

    Handling Unanticipated Load Spikes

    In production environments, loads can spike unexpectedly and for any number of reasons–ranging from simple sudden popularity with users to malicious distributed denial-of-service (DDoS) attacks. Whatever the root cause, applications must be well-prepared to withstand these events without failing.

    To ready applications to handle load spikes, rate limiting is a simple (but powerful) technique that allows operators to specify the request rates to front-end services. Implementing this safeguard through a routing solution answers the challenge of avoiding downtime due to surprise changes in load intensity.

    Securing Microservices Communications and Permissions

    Security is always a constant concern when it comes to operating production deployments. However,  microservices environments often have absolutely zero enforcement of internal network communications permissions. They also face the challenge of implementing proper encryption to secure sensitive data within both internal and external traffic. 

    While allowing any service to access any other offers flexibility, the risks are substantial. In order to safeguard microservices that access and expose sensitive data, it’s wise to limit access to only those client services with a vetted business justification. Routing technologies make it possible to enforce these secure policies using network segmentation.

    At the same time, routing solutions can help businesses encrypt the in-flight transport of critical data, which is not only a best practice, but in many industries a necessity from a regulatory compliance perspective. Service meshes can offer the benefit of providing secure TLS encryption for all internal east-west traffic, while edge routers offer to encrypt external north-south using a provided certificate. Also of note for north-south traffic: combining routing technology with services such as Let’s Encrypt can serve to fully automate lifecycle management of trusted certificates, eliminating the need for human intervention entirely.

    Achieving High Availability

    Leveraging software routing technology to achieve high availability is more cost-effective and efficient than traditional hardware failover solutions. It offers the opportunity to build production microservices environments that are quite resilient. For example: Routing implementation should utilize a highly-available architecture that includes a horizontally scalable data plane and a separate fault tolerant control plane. While the data plane allows for adding instances as necessary to meet capacity and resilience needs, the control plane is prepared to tolerate failures and ensure that users experience seamless and uninterrupted uptime.

    Deploying Across Multi-Cloud and Heterogeneous Environments

    Larger enterprises often utilize deployments across multiple cloud and/or on-prem environments, each of which may rely on disparate container orchestration technologies. Highly portable routing technologies capable of supporting a range of orchestration tools can vastly reduce the challenges developers face in supporting multiple environments. This allows them to deploy the same familiar solution and a common routing layer model across deployments.

    Routing technology is a key variable in determining the capabilities and ease with which DevOps teams are able to overcome challenges to the success of their production microservices deployments. By making a carefully considered choice in selecting a routing solution, teams can better prepare for these challenges–or even avoid them altogether.

    — Manuel Zapf

  • Never Ignore the E-Factor

    Never Ignore the E-Factor

    When cloud burst upon the scene, we were treated to wild-eyed prognosticators telling us about the death of the traditional data center. This is a trend in IT that you would think we’d learn from, but we repeat every couple of years. 4GLs, no, XML, no…Were all going to end development, and yet here we are, with more lines of code and more programming languages in use. It just keeps happening.

    These all share two common failings. First, technology in use today may not be perfect, but it is getting the job done, so dumping it for the new silver bullet is an unlikely result either in the long or the short term. For example, we’re many iterations beyond the conception of the C programming language, and yet for some purposes it is still going strong–because it does the job.

    But that’s a little tangential to today’s discussion. Today, the other failing is where I’d like to focus. The E-Factor.

    Enterprises are a lot of things, but one of the things the successful ones are not is careless. Cloud use in the enterprise was always going to be both multi-cloud and hybrid. Why? Multi-cloud because sole supplier arrangements are riddled with possible issues, and hybrid because every enterprise has something they want to maintain sole control of or something that simply can’t be moved but they want to push toward newer environments.

    We were always going to have multiple choices, and successful enterprises were always going to use multiple of them. Containers facilitate this truth a lot. The ability to run containers pretty much anywhere makes them portable, as long as staff is familiar with the infrastructure of a given environment so they can support the container management system in that environment. But even without containers, a cloud portability solution was inevitable.

    There is a massive amount of automation going into IT right now, all for the good. Freeing up traditionally scarce IT hours to focus on more and better services is all to the positive. Inevitably, one or more of these automation tools will be hailed as “The End of X.” Ignore them, and keep rocking at your job. AIOps seems most likely to gather this type of following right now. It will offer a flood of new data and consolidated views of that data, but not much else in the near term. Even when decisions start to be automated, full-on automation based upon AIOps feedback still needs code to run against and infrastructure to run on, so no doom and gloom there.

    Apply the E-Factor to anything hailed as a silver bullet. If you’ve worked in the enterprise, you know there are so many variables in the datacenter that any silver bullet would have to be a splintering round, each splinter behaving in a completely different manner to address current IT needs. More options are always good, and I, for one, go after new tech because I’m non-stop curious. But it is indeed just more options for your IT needs. Use the ones that will help, ditch the ones that make things worse and ignore the cheering “This time we mean it!” crowd.

    — Don Macvittie

  • Multi-Cloud Adoption to Better Enable the Developer Workforce

    Multi-Cloud Adoption to Better Enable the Developer Workforce

    Over the past decade, we started to see a broader shift toward the use of multiple cloud providers by the enterprise. The need to reduce risk, optimize cloud usage, manage costs and the push to open source and cloud vendor-agnostic technologies are providing more options for developers, which will likely lead to an even steeper increase in multi-cloud usage.

    In 2019, we saw the acquisition of Red Hat by IBM, the largest software company acquisition in IT history, to support both cloud and open source software. This acquisition, and others such as Salesforce/Tableau and Google/Looker, suggest that the trend will continue moving forward. In addition to support from mergers and acquisitions, multi-cloud within companies and use by developers will continue to rise.

    Multi-Cloud to Better Enable the Developer Workforce to Keep Up with Competition

    Multi-cloud architecture allows companies to distribute, move and optimize workloads across multiple cloud environments, decreasing the risks and costs associated with running workloads on only a single cloud environment and allowing one to select the best mix of capabilities for the desired use cases. These benefits make the single cloud option far less popular, and results in more interest in multi-cloud deployments.

    This choice is important–to keep up with the competition, digital businesses across the globe need to make better decisions and deliver faster, smarter actions. They must capture and integrate data in real time from wherever it is located, govern these data assets and augment the intelligence of their business through deep analytical insights. These actions must support both the technical and business levels of the enterprise, and developers must be armed with the right tools to enable these capabilities. A multi-cloud strategy ensures that this is possible, and offers the greatest degree of flexibility and choice when it comes to building solutions.

    To further support this shift, it is important to provide developers with the flexibility to choose best-of-breed solutions in order to streamline their processes. Limiting developers to one cloud vendor can restrict them from using the best tool for the job and result in suboptimal cloud deployments. But with a multi-cloud approach, developers can create their own individualized arsenal. Executives, who expect the best from their developers, have to pursue a multi-cloud strategy in order to get the most reliable and fastest results for their business. 

    Industry Insights for Mature DevOps Teams 

    Last year, IBM released research that showed that 85% of the companies surveyed were already multi-cloud adopters. Approximately 39% of those companies have implemented DevOps processes, and 41% have a multi-cloud management strategy. Clearly, multi-cloud is important to the strategy of an organization. 

    As pointed out, in order to be successful with a multi-cloud strategy, one of the key issues for developers to tackle is the creation of strong, automated DevOps processes. These processes must bring structure to a multi-cloud computing ecosystem. According to 2019 research from GitLab, overall DevOps adoption is on the rise, and teams that have successfully implemented a mature DevOps program are seeing major improvements in their workflow. In addition to speed, mature DevOps teams are almost 1.5 times more likely to feel innovative and are three times more likely to discover security vulnerabilities earlier in the pipeline.

    Future of Multi-Cloud Adoption and Impact

    Moving forward, we will see more companies adopt multi-cloud strategies and developers will be among the groups that are most impacted by this approach. For developers, multi-cloud adoption involves matching the business case for certain problem sets to the appropriate cloud providers so the expected ROI can be achieved with the right technology blend. 

    Developers need the right tools to develop, test, support, manage and monitor the deployed solutions consistently across cloud providers. Over time, it may also be necessary to move the solutions from one vendor to another as the requirements, business landscape and cost justifications change. Thus, developers must work within the organization to evaluate and choose the relevant features from each vendor, augment as necessary with external tools and regularly monitor industry trends and capabilities to transition if needed. This is the flexibility that a multi-cloud approach brings, but it must be balanced with the strategy, business and financial needs of the organization.

    The cloud will continue to be a strong technology focus area for enterprises and developers across the globe. Cloud adoption strategies will continue to broaden and shift toward multi-cloud as needed, allowing developers to streamline their processes, select the best tool for the job and create more value for their company as a whole.

    — Nelson Petracek

  • The Acceleration of Data and Data Storage Trends

    The Acceleration of Data and Data Storage Trends

    There’s never been a more exciting time for data. Increasing demands for size, speed, performance and reliance have propelled the data market forward at a faster rate than could have ever been anticipated, and new technologies are making some dreams for data a reality.

    From open source adoption in place of legacy databases to cloud-native app stacks and more, here are seven trends driving the acceleration of data and data storage. 

    Oracle’s Slow Fade Drives Cloud-Native Adoption

    Organizations of all sizes continue to eschew Oracle for cloud-native databases, shrinking the user base of the monolithic legacy provider. Two major trends driving this activity are the ongoing move to microservices-based redesign of applications and the rise of cloud-native deployments running in public clouds or Kubernetes. Overall, Oracle has lost market share every year since 2013, and legacy relational database players have dropped about five percentage points per year. Major organizations, such as Amazon and Salesforce, have already figured out that it’s to their benefit to use less, not more, Oracle.

    Open Source DB Usage Increases

    Open source databases that claimed 0% of the market 10 years ago, now make up more than 7%. It’s clear that the market is shifting and an increase in open source database adoption is on the rise. This goes against the recent trend of database and data infrastructure companies abandoning open source licenses for some, or all, of their core projects. However, as technology rapidly advances it will be in the best interest of database providers to switch to a 100% open source model, since freemium models take a significantly longer period of time for the software to mature to the same level as a true open source offering.

    Furthermore, Gartner predicts that, by 2022, more than 70% of new in-house applications will be developed on an OSDBMS or OSDBMS-based dbPaaS. It’s clear that open source has proven to be the most successful approach to developing and distributing business-critical infrastructure software, driven by the benefits of reduced total cost of ownership, access to community support and innovation and compatibility with commercial databases, making it easy to migrate towards an open source solution. 

    Kubernetes For Stateful DBs

    There has been continued growth in the adoption of both microservices and containerization. With the combination of massive adoption and the support of a large and thriving open-source community, it is clear that the dynamic nature of containerization and microservices deployments will have huge implications on fundamental application architecture. To put it simply, this is the future of how applications will be built. This is also why the adoption of Kubernetes has continued to grow.

    Multi-Cloud Goes Mainstream

    Multi-cloud deployments are becoming the norm in today’s enterprise. A multi-cloud approach is critically important for organizations that run on-premise, since they need to stay in a hybrid mode when moving microservices to the cloud. As a result, enterprises are widely embracing distributed SQL databases to ensure agility without the availability constraints of traditional monolithic databases, such as Oracle. 

    Rise of Edge Data Centers

    While the rise of edge data centers is assuredly a trend, Gartner predicts that three quarters of all databases will either be deployed or migrated to a cloud platform by 2022. There will also be an increase in multi-cloud adoption as a result of the geo-distribution of data. Edge data centers are already starting to offer data services with geo-distribution, a clear sign that demand is creating supply.

    Cloud-Native App Stacks Gaining in Popularity

    Modern microservices-oriented architectures are becoming increasingly popular. Over time, this leads to environments with lots of microservices that should be able to notify one another of changes and store these changes in a system of record. The application stack that is getting very popular for such use-cases is a combination of:

    • Spring framework to build the applications.
    • Kafka as the message bus to send notification between the microservices.
    • A Distributed SQL database to store the data in a scalable manner and query it efficiently.

    Other application stacks that are rising in popularity are the JAMstack ( Javascript, APIs and Markup) where there is no dependency on any particular web server. Javascript frameworks such as ReactJS and VueJS have become very popular for building the frontend portion of the app. GraphQL frameworks such as Apollo and Hasura are getting increasingly adopted as efficient ways to build the API portion of the app.

    Advances in innovation for data and data storage will undoubtedly continue, driven by major trends across all areas of business, as long as organizations are prepared to embrace change and hit the accelerator on their data strategies.

    — Karthik Ranganathan

  • The Top Six Cloud Computing Trends of 2019

    The Top Six Cloud Computing Trends of 2019

    Cloud computing was one of the hottest topics in the technology and business media throughout 2019. This is no surprise as the cloud sector has been growing rapidly for the last few years. Synergy Research Group recently reported a 37% overall growth year-over-year in public cloud. They also note that it has taken just two years for the public IaaS and PaaS markets to double in size and their forecast shows them doubling again within the next three years.

    While steady growth was expected this year, a few trends of note stand out. When the experts look back at 2019, they will likely stress the following cloud computing trends shaped the year.

    Rise of the Enterprise Cloud Manager

    We recently did a study on ParkMyCloud users which showed that a growing proportion of company technical leads have cloud or the name of their cloud provider–such as AWS–in their job title. This indicates a growing degree of specialization for individuals who manage and architect cloud infrastructure. Whether called enterprise cloud manager, cloud architect or something similar, 2019 saw the rise of a specialized role to oversee and direct cloud operations.

    Consolidated Multi-Cloud Views

    As enterprises large and small continue to adopt and use more than one public cloud, we have seen a rapidly growing need for a consolidated multi-cloud view and ability to take actions across multiple clouds in 2019. Third-party tools that do this provide enterprises the ability to pick a single tool to orchestrate, manage, govern and optimize their hybrid and multi-cloud environments. Many customers also sight the need to simplify operations—native cloud provider tools are not always easy to use.

    Multi-Cloud Arrives

    Multi-cloud truly arrived in 2019 and will only grow in 2020. The majority of organizations now use multiple clouds. In fact, most studies suggest that more than 80% of enterprises have a multi-cloud strategy. Reasons cited include the need to avoid vendor lock-in, the ability to leverage the best in class cloud services from each cloud provider and application efficiency choices.

    More Automation

    One of the biggest tech benefits to a DevOps approach is automating away the manual tasks that bog down operations and critical projects. Thus, the trend toward automation continued to expand in 2019.

    More Abstraction

    IT became more and more abstracted in 2019. This means container usage grew, along with models that allow developers to worry less and less about infrastructure (such as serverless and PaaS).

    Containers Became Mainstream

    Application containerization is more than just a new buzzword in cloud computing; it is changing the way in which resources are deployed into the cloud. More and more companies utilize container services such as Kubernetes and cloud native services such as EKS, AKS and GKS in 2019, 

    Business continued to move to the cloud in 2019 and the six trends described above showed that the sector is growing–sometimes in unpredictable ways. Next year will, no doubt, also contain some surprises. But the trend for expansion of the cloud and related services is unmistakable for the foreseeable future.

    — Jay Chapel

  • DevOps Chat: The Kubernetes and Multi-Cloud App Journey with Rafay

    DevOps Chat: The Kubernetes and Multi-Cloud App Journey with Rafay

    After Akamai acquired his company, Haseeb Budhani decided to take on his next challenge and start Rafay.

    Rafay focuses on the complexity and repetitive aspects of deploying and managing Kubernetes applications. Rafay addresses complexity by providing application abstraction, cluster blueprinting and enterprise-ready integration, making Rafay a great candidate for multi-region, multi-cloud, hybrid and edge/MEC adoption.

    Join us on this episode of DevOps Chats where Haseeb shares some of the experiences and challenges that led him to found Rafay, and how to accelerate your path to Kubernetes and multi-cloud applications.

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

    Transcript

    Mitch Ashley: Hi, everyone. This is Mitch Ashley with devopsy.kinsta.cloud, and you’re listening to another DevOps Chat podcast. Today, I’m joined by Haseeb Budhani, CEO and co-founder of Rafay. Our topic today is lifecycle management for containerized apps. Haseeb, welcome to DevOps Chat.

    Haseeb Budhani: Mitch, thanks for having me. Great to talk to you.

    Ashley: Yeah, nice to talk with you. Always love talking with a fellow entrepreneur. Could you start by just introducing yourself, a little bit about your history, what you do and a little bit about Rafay?

    Budhani: Absolutely. So, Rafay the company is slightly under two years old at this point. We have a product available on the market that a number of customers are using which, essentially, helps them simplify the ongoing operations and life cycle management for their containerized applications, which they may be running in public cloud, hybrid environments, or any combination thereof.

    Fundamentally, there is a brunt of work that every company does as it relates to ongoing management of the containerized apps. You know, essentially, they build a platform internally on top of Kubernetes, and our pitch is, “Hey, why are you spending time rebuilding the—kind of reinventing the same build over and over again in every company? Let us help you with our solution which focuses on the repetitive effort that every company goes through, so that you, Mr. DevOps Engineer, can focus on the true value that your company is looking for out there. So, you focus on company value. We’ll help you solve for the repetitive work that you have to do, anyway.”

    Ashley: Very good. Now, you started this company after selling your prior company, Soha Systems, to Akamai, I think you took about a year before you jumped out and started Rafay. So, why did you pick this particular problem? What was it about it? Was it something you experienced in Akamai, in your prior company, or just as you were kinda taking that time to really think about what you wanted to do next? Why did you pick this space?

    Budhani: Yeah. You know, Akamai, it was, surprisingly, a lot of my friends who’ve kind of seen exits, you know, kind of, they talked about acquiring a company, it was tough, and I didn’t like the experience or whatever. I actually had a lot of fun at Akamai. It wasn’t as stressful as it used to be. I mean, you know how stressful startups are, so it was a pain-free experience, really. You know, an incredible sales organization. They really understood our product, took us to this whole new level.

    But, you know, sometimes an idea gets stuck in your head and it’s just impossible just to walk away from it. So, in our prior startup, so pre-acquisition by Akamai, we were practitioners of the problem that we are trying to address. So, essentially, we were the customer.

    Some of our colleagues at Soha were effectively building a platform like the one I just described, wherein we were kind of writing at this layer on top of container orchestration so that we could be running our application across many locations. So, at the time of exit, we ran—I don’t know, somewhere between 20 and 30 POPs globally across multiple cloud providers just so we could have our cloud based security platform at Soha running in a number of locations globally.

    And it was very, very painful. And I think at that point, we didn’t realize that when you’re building a platform, when you’re so focused on the core value which is the security, you know, this DevOps thing is important, but you don’t spend as much time strategically think about it. And that, after the acquisition by Akamai, Hemanth, my Co-founder at Soha and also here at Rafay, we spent a lot of time thinking about this. Like, why did we have the experience we did? Because it was not a good experience. And then we thought about, “Well, who else has this problem?”

    It turns out everybody has this problem where anybody building a SaaS platform or running applications in the cloud, particularly when it comes to containerized apps, because the community is so new, there is a whole lot of supporting cast, if you will—mythic. And it’s gonna come. It’s just, right now, it’s missing because it’s so new. And that got us thinking, “Well, somebody’s gotta solve this problem.” You know, and when you kinda look around and say, “Somebody’s gotta solve this problem” and nobody raises their hand, maybe you should do it.

    So, that got us thinking, “Well, we should—we need to go solve this problem.” So, we left. And I’m sure both of our wives were very unhappy when we said we were gonna leave Akamai. [Laughter]

    Ashley: [Laughter]

    Budhani: But—no, it was a worthy cause, and we’re very happy we left because we solved a really important problem for the community.

    Ashley: Well, congratulations for starting another startup. I think it’s one of those kind of in your blood type of things. So, talk a little bit about what’s unique about Rafay. I’m assuming you took some of the same problems that you experienced of what you’ve built at Soha and probably along the way said, “Hey, you know what? This might be a good idea for a product for containers and containerized apps.”

    And I think I would just add to the conversation by saying, as you start to build larger and larger containerized apps, you realize what some of the management challenges really are around it, and so that’s, you know, borne out of that is a new opportunity. I’m assuming you had a similar kind of experience.

    Budhani: Exactly right. You know, you read some blogs about, you know, like, Kubernetes. And it makes things look very easy. You can get something up on your laptop and you’re like, “Oh, look! I have a Kubernetes cluster running on my laptop! Isn’t this easy?”

    Ashley: [Laughter]

    Budhani: No. When you run it in production with multiple applications, it’s hard, and everybody knows it, this is not new information. But the challenge is that, because there is as yet no manual for this, we only learn by doing. So, we have to kind of jump into this and we start building stuff, and then we go, “Oh, this is hard,” and then by that time, we already have pretty large teams in most companies who are working on this. And that’s the problem and, of course, that is the opportunity, also.

    Here’s a better way of thinking about this. So, because of our experience at Soha, some things we recognized. Not everybody on our team we could train to be experts at the platform.

    Ashley: Mm-hmm.

    Budhani: Some people are experts and most people are not gonna be. And this is very typical in most companies, you have a DevOps team of five, seven, 10, 20 people who build a platform and then another hundreds or thousands of engineers, depending on the size of the company maybe consuming the platform. Because basically, they need to understand this—they need an abstraction layer. That was a key insight for us, having spent time talking to companies, you know, once we were out kind of looking at, you know, what do we do next?

    So, everybody seems to need some notion of an abstraction layer so that I, as a developer, I check in code and just magically, my application shows up somewhere. I don’t want to think about this underlying complexity. And the second thing that we saw, which VMware, surprisingly, validated two weeks ago when they did a bunch of announcements at VM World was that nobody’s running a single cluster.

    Ashley: Mm-hmm.

    Budhani: They may start with a single cluster, and because it’s easy to keep adding nodes to their cluster. But the practical approach around clusters is to run many small clusters. And VMware spent a lot of time talking about this idea of many small clusters.

    So, that implies solving for multi-cluster operations, multi-cluster federation is a critical thing. And that continues to be a gap in the community right now. There are a number of approaches that have been taken to solve for multi-cluster federation in the community, but—and, you know, a lot of companies have talked about this, there are tools that exist out there to solve this problem, but fundamentally, they make certain assumptions that are not borne out in practice. And that was a unique thing that we saw as a gap and we addressed it very elegantly in our platform.

    There’s a number of things we do, for example—I’ll give you another example. And anybody listening to this podcast, as you hear this examples, you may kinda look back to your experiences and go, “Yeah, I’ve faced this.” So, you bring up a cluster. Let’s say you are some e-commerce company. So, you need some clusters that need to be PCI ready, or PCI compliant. Some clusters, for marketing, because all they do is some experiments—I don’t need to be stringent for them. And then you have people who are just writing code, developers.

    So, you need a blueprint for a cluster, because each cluster may need different things. How do you do that? It’s not easy. It’s not easy. You know, there’s no kind of help chart for help charts. What do I do then? These are some of the problems, right?

    So, if you really spend time talking to the DevOps community, these are some of things that they struggle with and today, they all take a bunch of open source tools and try to build something for themselves. Some do it very elegantly. Some just never get to that level of perfection because they are so busy. And this is my pitch to every customer. My entire team, all of us—we do one thing. We do one thing. We help you run your containerized applications.

    Ashley: Mm-hmm.

    Budhani: You have 50 things to do. Let me help you with this, right? Let us be an extension of your team. Let us, you know, really take this one stress away from you—of course, pay money for that, [Laughter] but focus on the things that are more important to the company.

    Because getting the right script in place or whatever in place just so you can run your Kubernetes and run it better—this is not how you make money. If your competitors all ended up buying from a vendor to solve this problem versus build it themselves, they’re gonna probably sell a single more unit of widget that you’re selling, right? Focus on the value. Don’t focus on the very complex but effectively undifferentiated work.

    Ashley: Well, what you’re saying makes a lot of sense of why rebuild it all yourself? Why learn all the hard lessons that others might have learned? And I take it that you do things through your abstraction layer with your blueprinting of essentially kinda creating what we might think of in software as here’s patterns that we might use, here’s blueprints we might use for different clusters.

    Budhani: Yeah.

    Ashley: And I know a common mistake I’ve seen happen is, it’s really easy to throw everything into one cluster and then start to say, “Well, that doesn’t work. How do I start dividing it up into, besides just geographic location, what are the other techniques for doing that?” So, those are the kinda things that you’re bringing to the table with Rafay, is that correct?

    Budhani: Yeah, absolutely. Yeah. I mean, I’m sure many of us continue to have the Design Patterns book from college on our shelves, right?

    Ashley: Sure, yeah.

    Budhani:[Laughter] That’s the idea, right? Some things are best done in a specific way, and if there’s a way to do that, if it’s a best practice way to do it, you do it. Not every company may have their own quote-unquote blueprint, and that’s okay. But let’s help you manage those better.

    In effect—you know, and this is fundamentally, we talked about, practically, what Rafay is selling today. But if we fast forward three, five years, we sell something today, but we still have to have a raison d’être, right? Why are we doing this? I think, fundamentally, there is a system of record needed in our industry that maybe doesn’t exist as well as it could. Where is that one place in a company where I can go and say, “Hey, where is ____ right now? How is it doing? Three months ago, how was it? Who changed what last time? Where is that information today?”

    It’s in people’s heads, sure. It’s in a Git repository. We all talk about GitOps, right, which means somebody wrote a script and checked into a git repo. Yeah, but maybe the guy who wrote that script left six months ago—now, who understands that script? That is a very common occurrence—people write scripts and then they move onto the next job. Where is that system of record? Where is that system of governance for an application?

    Particularly with containers, there is an opportunity to very elegantly address that problem, right? Have a system that allows you to do that. One system where somebody who is non-technical can log in and say, “Hey, just from a compliance perspective, is this app running on all the right clusters right now, or not? One shot, can I know that?” That is where I think we will all go as a community.

    And as I kinda think through what are those bread crumbs to get us there, some of the things that we are working on as a product company today, my hope is that we get there. We get the opportunity at Rafay to build that system of record that people will really treat as a strategic system for their own companies. Anybody in the company should be able to come and look at, “Hey, where is my—what is the status of my app right now? How has it changed in the last month?” That, to me, is such an important and worthy goal to be focused on. Let’s see how—you know, what it takes for us as a group to get there. But that, man, that—I mean, somebody needs to go solve that problem.

    Ashley: Now, I haven’t used your product, but one of the things that I found really intriguing about your go to market and how you talk about it on your website is, you actually present use cases, more than just generic things, but something specific to, like, factory operations for IoT and customer experience app, modernizing in store retail experiences, 5G, edge deployments. Are those part of the kinda blueprints of what you talk about, or is that more, you know, on a broader scale, “Here’s how we might advise you about how to implement a containerized cluster environment?”

    Budhani: So, these are the business use cases that are—the last one we talked about was this retail use case. It’s a fascinating problem. Many retailers are out there talking to larger vendors and in some cases to their ____ providers who happen to be large customers. And they’ve asked the question, “Hey, I want to deliver a better experience inside my store. Is the point of sale system in the retail store up or not?”

    That’s a good question. How do you find out? We can’t run these tests from out of the store, because that’s a private network, basically. So, I wanna run an app inside my store. Oh, yeah? Where do I run it? Where is this infrastructure? This is not a—there’s no data center, here. They have probably one rack in the back somewhere, maybe with one or two machines. So, then maybe I should run containers here—but then, who’s gonna manage my containers, because I have 1,000 stores, it’s not one. And if I have to send IT people to every store to deploy an application and upgrade it regularly—well, I need an army now, right?

    It’s just a small question. I need to run a small, tiny, 200 ____ app. It becomes this big thing. What an interesting problem. But this is a real problem. Think about any retail location where they have a lot of refrigeration capability. They’re selling ice cream or they’re selling whatever drinks and whatnot. If any one of these refrigeration units is not working, you lose a lot of money.

    Ashley: A very big deal.

    Budhani: And, of course, it’s a bad—right? So, they run these sensors, okay? Who’s collecting this data? Where is the sensor running? Is it a tiny little sensor? But then the sensor data has to be collected maybe locally. Okay, what do I do now? Right?

    All of these small things, these are real business problems that kind of snowball into this bigger problem around application management, right? So, if I—if you consider, if we called a retail store or some head office for some retailer and said, “Hey, do you wanna buy a container management platform or life cycle management containerized app?” Like, “What is a container?” Right? [Laughter]

    Ashley: Yeah.

    Budhani: Their people know, but they may not know, right? But they understand this problem, right? It’s like, “I need to run apps here, because this is how I’m gonna make more money. I want to provide a better online and offline experience for my customers.” That opportunity, right?

    So, that’s why, as we hear use cases, as we partner with different companies, and we see very specific and repetitive use cases come up again and again, our hope is that we continue to list them on the website. So it’s more meaningful for even the business or more kind of—you know, non-technical people in the company to come to a website like this and understand why, you know, their engineers are talking to us, for example.

    Ashley: You described yourself as a SaaS based company, it’s a SaaS service. Do you also provide any operations support, kinda outsource of operations, too, or is it strictly a service that others then operate on top of your SaaS?

    Budhani: So, it’s a service, and we do provide kinda more of a solution architecture model ready to essentially assist in our customers thinking through how they’re gonna consume a platform like this, right? Because a platform like this is not—it’s not a box that you plug into your network, if you will. This is a strategic conversation where we’re thinking about how to embed it in some way into your processes or into your, you know, own organization.

    So, there’s some level of consultative conversations that are happening up front, definitely, and on an ongoing basis, also. But from an operations perspective, we don’t see that when Rafay is fundamentally a software company, you know, a lot of pre-sale support on the solution side. We are continuing to engage with a number of companies who excel at that, who look at Rafay as an enabler not just for themselves but for their customers to whom they’re delivering a broader service. So, think systems integrators, DevOps consulting organizations who, whether Rafay exists or not, they are solving this problem and they have other customers, right?

    Ashley: Mm-hmm.

    Budhani: So, those companies look at us as an accelerator for their own services and for their own offerings. So, that’s been how we’ve been approaching the market, so we can obtain a high margin business and be, effectively, a software company. That’s what we know how to do well. But there’s so many great organizations out there who have an incredible skill set as it relates to operations and integration. That’s where we step back and partner with somebody, and at that point, be our tool in the tool chain and they go deliver a great experience to their customers.

    Ashley: Very good. That helps a lot. So, talk about who your most ideal customer would be. Is it a large enterprise, medium to large? What kind of an organization would say, “This is exactly what I need—come help me”?

    Budhani: In theory, this is a horizontal problem. Anybody who’s doing, you know, running containerized applications has this issue. But fundamentally, what we, at different stages in the company, look for different kinds of companies in terms of just, you know, low hanging fruit, et cetera.

    What we find works well today is, you know, relatively mature organizations who are doing somewhere between a couple of hundred million to a billion dollars of revenue, they are modernizing their applications, moving to the cloud, becoming more and more cloud native. And they’re the ones who are very interested in going fast, because there’s some—usually, there’s some business reason why we’re doing this. They’re not just modernizing for the sake of modernizing, there’s competitive pressure, there’s cost pressure. They may need to be in different parts of the world, et cetera.

    There’s reasons why they need to be up and about quickly, and they will look for any shortcut to get them there. A shortcut in this case would be, you know, “Hey, I could build this myself. Should I?” Right? And what I just said, right? This is a question we, in some way, shape, or form always want to highlight to our customers, which is—hey, you have a really strong engineering batch. You can do anything. Should you do everything? Do you still build data centers? And that, of course—that’s a, you know, asking the question, “Are you still using, building data centers?” that’s a straw man, of course. Because, hey, I mean, maybe other than 100 companies in the world, nobody’s building data centers any more.

    Ashley: Right, right.

    Budhani: It makes a point. In our industry, we continue to go up the stack in terms of abstractions, right? I mean, all the way from assembly to op and now nobody’s building subnets any more. Private subnets, published subnets—you just make an API colony and you get one in Amazon, right? Why am I building this stuff?

    Similarly, we are providing them yet another level of abstraction which allows them to move faster. Because fundamentally, the name of the game is, “Hey, if I don’t move fast, if I don’t produce product fast, I’m gonna lose.”

    Ashley: Now, I know you worked with AWS as your et cetera VMware. Is there a particular environment that you’re best suited for? Like, if you’re a VMware customer, you’re gonna—we’re gonna connect right into your environment, or is there a technology stack that’s more easy for you to integrate than others?

    Budhani: So, this is a very agnostic platform. I mean, VMware environments can be anywhere. And I’ll highlight a specific thing that we’ve thought through and we implemented as part of the platform.

    So, let’s assume for a minute that it’s a mature organization, they do have some hybrid environments, and they maybe have some Tectonic set up and they’re running VMware there, and they also have Amazon, and that’s okay, right? So, in one environment, maybe they’re using PKS from VMware, PKS Essentials from VMware. But in Amazon, they’re using EKS, because that’s what Amazon sells for Kubernetes.

    Okay, now what do I do? Am I gonna build two sets of platforms to support two different environments? Not a lot of people do that. Or, with a platform like ours, what we say is, “Hey, just—look, if you have an opinion on Kubernetes, go with it, and essentially, we’ll add value on top of your existing Kubernetes throughout the operator.” It’s a Kubernetes concept called an operator.

    Ashley: Mm-hmm.

    Budhani: Or, if you don’t care and if you say to us, “Hey, you know what? Just bring me the, I don’t know, whatever the latest upstream Kubernetes is, 115 or whatever—just bring that.” No problem, we’ll work with that, also. But, for our SaaS platform, to help you manage your environments behind a firewall in a data center or behind a security group in Amazon, you don’t ever happen to open a single portal in the firewall for us to get in from outside. The entire system is designed to be secure such that there are sessions being launched from inside out, so your clusters run an agent, basically. They reach out and broker all the connectivity without making a security issue kind of pop up on the security team’s radar.

    So, this is another thing, by the way—anybody listening to this podcast thinking about some sort of a multi-cluster or multi-cloud solution? Please let’s make sure that you’re not signing up for a vendor who’s asking us to make maybe not the best decisions when it comes to security and asking us to open up ports, setting up IPsec links—you know, all of these are bad ideas that lead eventually to other problems that you haven’t thought about today.

    So, these are some of the things where understanding our enterprise security, understanding our enterprise problems are important up front, so we thought through these things and we designed a platform to be able to work not just in any environment, but to work in these environments in a very secure fashion.

    Ashley: Well, certainly, I think, with all your experience, you can help de-risk things and provide kind of a framework or a path for enterprises.

    Well, unfortunately, we’ve run out of time. See, I feel like we could talk about this for another hour and a half and share a lot of good stories about it, too. I’d like to thank you—thanks for being on the webcast, the podcast, here.

    Budhani: Yeah, thanks for having me. It was a really fun conversation. I look forward to talking again soon.

    Ashley: Yeah, I do, too. Keep us informed about any new news. So, I’d like to thank our guest today, Haseeb Budhani, CEO and co-founder of Rafay. I’d also like to thank, of course, you, our listeners, for joining us today. This is Mitch Ashley with DevOps, and you’ve listened to another DevOps Chat podcast. Be careful out there.

    — Mitchell Ashley

  • DevOps Chat: Hybrid, Multi-Cloud Management for DevOps With CloudBolt

    DevOps Chat: Hybrid, Multi-Cloud Management for DevOps With CloudBolt

    Agile, DevOps, multiple cloud providers, serverless, contemporary cloud native apps, shadow IT using a credit card–it can be daunting for any IT organization to be responsive to the internal customer needs. It’s even tougher to be proactive and get ahead of the curve. Enter Cloud Management Platforms (CMP).

    On this episode of DevOps Chat, we talk with Bernard Sanders–no, not the presidential candidate–CTO of CloudBolt. Our conversation explores how IT can use a CMP to provide the IT and self-service capabilities so DevOps and Agile teams won’t feel the pain and slowdown of IT past.

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

    Transcript

    Mitch Ashley: Hi, everyone. This is Mitch Ashley with devopsy.kinsta.cloud, and you’re listening to another DevOps Chat. Today, I’m joined by CTO Bernard Sanders from CloudBolt. Our topic today is DevOps for hybrid and multi-cloud environments. Bernard, welcome to DevOps Chat.

    Bernard Sanders: Thanks, Mitch. Great to be here.

    Ashley: Super good to have you on the podcast. Would you start out by introducing yourself? Tell us a little bit about you and also a little bit about CloudBolt.

    Sanders: Sure. So, I’m Bernard, CTO and co-founder of CloudBolt, and spent most of my career in the data center automation/DevOps/cloud management space as it’s been known throughout various eras, you know, since 2000 when I started in the industry. And I’ve gotten to see a lot of different enterprise IT shops and how they work—what goes well, what goes wrong. I spent a lot of time in IT shops and the financial services industry and in retail and government, and it’s been interesting seeing the commonalities between these.

    And it was through an observation of those commonalities and talking with a colleague of mine, Augie, that we decided to start CloudBolt software in 2011 and started working on the software, put out first GA release that year. And CloudBolt is a hybrid cloud management platform, sometimes called a CMP. It essentially helps large organizations who have a data center presence and also want to use the public cloud. It helps them consume both from a single interface.

    Ashley: Cool. Well, first of all, I have to compliment you—anybody with a buddy named Augie has to be a good person.

    Sanders: [Laughter]

    Ashley: Augie sounds like a great guy. [Laughter] So, this was like, sort of from your garage, kinda from the basement type of startup that you two started it originally and got this company rolling?

    Sanders: That was basically it. We did have a leg up in that we were working for a consulting company at the time based out of Washington, D.C. named August Schell, and we spun this company out of August Schell. So, starting up, the two of us and the others we brought on were able to focus on the technology and the solution and going and getting some customers, and we didn’t have to worry so much about the back office stuff—the HR, payroll. We piggybacked on our parent company’s infrastructure for a lot of that, so—

    Ashley: Nice. So, kind of a spinout or bootstrap off of the parent.

    Sanders: Exactly, yep.

    Ashley: Very nice. Alright, well, you know, not everybody gets to start out doing cloud applications in a cloud-native format, or even just within one cloud. You know, oftentimes, we’re saddled with complexity, we’re saddled with the existing applications—I don’t mean it in a bad way, it’s just the reality of the business—or we’re part of a digital transformation moving to the cloud, which is sort of where we get these hybrid and multi-cloud environments.

    What are some of the challenges that you saw that set you about, “Let’s go start this company, build this cloud management platform.”

    Sanders: Yeah, yeah. So, there’s a couple areas to discuss there, you know, the first of which you touched on is that not everybody gets the luxury of starting greenfield. You know, if you’re starting a brand new software company with a few people and a few needs for servers, you could start entirely containerized, serverless with the latest technology. But so many companies we talk with, still ask us, “Oh, do you support mainframes? Do you support AIX, do you support HQX?” [Laughter] The answers to those questions are no, in our case, you know? We gotta draw the line somewhere. But there’s a very long tail of technology at these enterprise companies. There is a need for stability and continuity and they can’t just drop everything and move to the latest platform with all their applications.

    Ashley: You know, I like to say generations of technologies never go away.

    Sanders: That’s correct.

    Ashley: There’s probably code I wrote when I got out of college, scary enough, if we think about that. But yeah, it is. You’ve got to adapt to what you have. We can’t rewrite everything.

    Sanders: You know, your other part of your question was what problem did we see that inspired us to start CloudBolt, and what we were seeing, Augie and I, any time we went out to these large institutions is a breakdown in the communication between the IT department at a large company or organization and their end users.

    Ashley: I’ve heard that happens, yeah. I’ve never seen that, but I’ve heard.

    Sanders: [Laughter] Yeah. It just happens so much it’s almost a joke, but you know, end users will have to put in a ticket with IT if they wanna get a VM, either in their private data center or sometimes even in the public cloud. And then that IT group has to go do a lot of manual steps and there’s oftentimes a lot of hand offs between groups to eventually build that environment or that individual VM or network storage out and then get it back to the user. And it’s a black box and everybody gets frustrated with each other.

    Ashley: Mm-hmm.

    Sanders: We thought—there’s gotta be a better way to do this.

    Ashley: So, how organizations can work together more effectively, let’s also tease apart both the multi-cloud and the hybrid aspect of this. So, multi-cloud, do you find that’s because things sort of start up on their own and different groups go out and somebody starts on Azure because they’re Microsoft code, and somebody starts out on Amazon or Google or wherever and then some day, somebody else says, “Why don’t we pull this together?” Or is it more of a conscious, “No, we need these different cloud environments for these good reasons, so let’s put together a cohesive strategy or architecture for how we go about that?” How do those things evolve?

    Sanders: I think it’s both. I’d say it’s probably 60/40. A lot of times, it’ll be a company that says, “Oh, we’re all on Amazon.” Then they go acquire another company that does Azure and then another one that does something else. So, a lot of times, it’s that unintentional growth.

    Ashley: Mm-hmm.

    Sanders: But I think more and more, you’re seeing each of the cloud providers, they are diverging over time and they each have their own strengths and weaknesses. So it’s totally valid to say, “Hey, we’re gonna use Google Cloud for this one thing and we’re gonna use AWS for this other use case, because that’s where these platforms are strong.”

    Ashley: Interesting, interesting. So, talk about the hybrid part of this. You know, whenever there’s a new generation or a new shiny object, it’s like, everything is gonna go there. So, everything is gonna go to the cloud, and of course, many things have and some things have fully and some things have just partially.

    Sanders: Mm-hmm.

    Ashley: And there’s always that need. You talked about mainframes, for example. There’s that need of having a hybrid environment. How do you define a hybrid environment?

    Sanders: Yeah, so I define hybrid as using both a private cloud and a public cloud. So, private cloud meaning your own data center or, you know, maybe one that you colo or somehow rent out. But basically, your own gear, your own hardware and infrastructure, but also using the public cloud at the same time. And that—you know, I think that’s been one of the biggest about faces in the last five or six years is, if you went back five or six years ago, listening to a lot of the industry analysts, you would’ve thought that we’d be off public cloud, you know, a year or two later. Or we’d be off private—

    Ashley: Of private, yeah.

    Sanders: –and that would go totally extinct.

    Ashley: Of course.

    Sanders: And that we’d be completely on public cloud. But I think that was an unrealistic expectation. There was a Goldman Sachs study earlier this year that said 26% of workloads are in the public cloud. So, that leaves a huge portion that’s still a huge majority in the private environments.

    There’s a growing need for hybrid, you know? People don’t want to use both totally disjointedly, they wanna use them together in some way. That’s what I would call hybrid cloud.

    Ashley: That kinda sets the context for talking about this cloud management platform. Define that for us—what is a cloud management platform?

    Sanders: Yeah, cloud management platform is a tool which can provide a single pane of glass or interface as well as API to manage disparate IT environments, and that can be public cloud, private cloud, containers, virtual machines, physical. It can include serverless, it can include public cloud services as well as basically any request you would make of IT. That’s what I would call a cloud management platform or CMP. The other main defining characteristic is, it needs to provide self-service to end users. It has to be a tool where end users can go and get what they want on their own rather than asking IT to do it for them.

    Ashley: So, really, the ability for IT to manage its environment but also to provide portal access, if you will, if you thought about it that way, anywhere for people to do self-service, APIs, STKs, so DevOps groups can tie into the platform.

    Sanders: Exactly. Yep.

    Ashley: Okay. So, let’s go there. Let’s talk about how does DevOps fit into—IT wants to organize things, right? IT wants to get its hands around and be able to at least manage—you know, not necessarily control or constrain, but you know, they’re responsible for what’s happening in the organization with the technology and so, they want some form or semblance of management control over that.

    How do you do that and, at the same time, let the DevOps groups thrive and flourish?

    Sanders: That’s right. Yeah, so, really what it’s about is having the IT team, giving them a tool where they can set their policies, set the standards, but expose an interface, or multiple interfaces, to different departments or groups for those teams and DevOps folks within those teams to go get what they need when they need it and automate what they want on top of that base that IT has given to them.

    So, in the case of most cloud management platforms, the IT group would bring it on, purchase it, get it installed and set up and then expose that UI and API out to these departments who can code against it. So, the DevOps team in a particular department, for example, might have a CI/CD pipeline that calls into the cloud management platform that’s exposed by IT.

    So, both groups are empowered. IT gets to set the quotas and the approval process and the host name standards—like, everything policy related within that cloud management platform, and those end users and DevOps folks get to provision what they want when they want it.

    Ashley: I don’t want to make it sound like a panacea, but it sounds like this would be a path for an IT organization who maybe has lost control or doesn’t feel like they have their arms around everything that’s happening in the organization and they can become sort of the provider of the cloud computing infrastructure resources.

    Sanders: Absolutely.

    Ashley: And this could be a path to them kind of getting in front of what’s happening instead of just being reactionary.

    Sanders: Absolutely, yeah. The other effect that it has that we’ve seen, you know, CMPs have, whether it’s CloudBolt or a different one is that, you know, the private data center has lagged behind public cloud in terms of its interface. Like, going to the Amazon console or Google cloud, ordering a VM—it’s a pretty easy, fairly self-service process. It’s not that way with OpenStack or VMware and Nutanix. I know it was one of private virtualization systems people use.

    Having a cloud management platform levels up your private data center to a level that’s similar to public cloud where people can do self-service in the private data center, not just the public cloud any more.

    Ashley: Okay, so at risk of me sounding like I’m just happy ears and throwing you softballs—

    Sanders: [Laughter]

    Ashley: –what’s the hard part about implementing a CMP?

    Sanders: [Laughter]

    Ashley: It can’t be all roses and, “Here’s a credit card and download and—poof, your NPS scores shoot from 10 to 56.”

    Sanders: Oh, can I only name one thing?

    Ashley: Yeah. [Laughter] What are the challenges of getting from “life’s pretty tough” to, “we’re in a much better position now that we’ve gotten this platform in place”?

    Sanders: Yeah. So, for folks who bring in a cloud management platform, I think the challenges are oftentimes less technical and more organizational, because it affects so many different groups. You have to get people’s buy-in that, “Hey, we’re gonna do this thing. We’re gonna use this as our common interface to IT.” And that can be challenging. I think it’s made easier if the interface is good and you make it attractive and appealing and powerful and give them what they need in that interface, people will come to it. But it can still be hard enacting any kind of a change within these large organizations.

    Ashley: So, is it easier in a smaller organization, mid-sized or large? I can imagine maybe it’s easier in a large enterprise where you can sort of lay out standards and how you have a process for doing that or maybe mid-sized is tougher because it’s harder to herd the cats? I don’t know, what’s your experience?

    Sanders: That’s a good question. I think, just generally, any time you get more humans together, it’s harder to make change and to get them all doing the same thing. And, yes, if you have executive buy-in in a large organization, that can make it easier, but I think it’s still basically always harder to move more people than it is to move fewer people to a new way of doing things.

    Ashley: Okay. So, another, tougher question—why is CloudBolt better than the rest of the CMPs on the market? Why is it a better mouse trap?

    Sanders: [Laughter] Good question. You know, I don’t do a lot of the competitive analysis myself, but what I’ve heard from our customers is that they can get CloudBolt installed and running and get value out of it much more quickly than other platforms. You know, we’ve done demos before where, by the end of the demo, you know, where in a GoToMeeting or a Zoom meeting or we’re showing the product to a customer and by the end, they’re asking us, “Oh, where’s the button for X?” We have to pause and say, “Wait, what’s going on over there?” In the time it’s taken it to demo it to them in half an hour—so, they’ve downloaded it, installed it, connected it to their VMware environment, they’re, like, provisioning VMs. It’s a pretty nice bar, I think, we’ve hit in terms of consumability. They also talk about the extensibility being very powerful.

    We try to build all kinds of hook points and extension points, capabilities to let them extend it to do whatever they need it to. A lot of these IT shops have very specific requirements and systems and standards and ways they need things to operate, so they like that extensibility.

    Ashley: Well, teams doing agile, DevOps teams, you know, they build an environment around them where they can execute quickly because they can get access to resources quickly, you can go to Amazon credit card—poof, I’ve got whatever. And it’s great to build that kind of process and that environment around them. Of course, we run into things that are gonna slow them down, like quote-unquote IT, or some new thing, the shiny new CMP kind of thing.

    How do you get a DevOps team on board that’s been just fine going to Amazon and Google and Azure and whoever else to get what they need and now they need to go through this IT thingy that’s been placed in front of them?

    Sanders: Yeah. I think, really, what you need to do is solve problems that they’ve got, and CMPs do that. You know, when they see one interface, one API that is consumable and up to their standards and allows them to deploy to any different cloud as well as the private data center, usually, it doesn’t take much more convincing than that. They say, “Wow, we were gonna have to build that,” because we were just given the mandate to do two different clouds or to do VMware plus Azure.

    And now, we don’t have to do that ourselves—that’s great. We can build more functionality and just build on top of that great platform there.

    Ashley: Can you come in and work with an existing either homegrown automation, or if they’ve built around some build and automation tools for deploying both code and to the cloud? Can you work with tools that a DevOps team has already set up, or do you have to kinda retool parts of what they’re doing?

    Sanders: There’s usually very little retooling. There’s bidirectional integration that usually happens. You know, if somebody’s gotta build pipeline in Jenkins or Concourse, they’ll oftentimes have that start calling into CloudBolt to do those builds, and they can sometimes remove some of the complexity from their systems if they were calling directly into infrastructure to do that themselves.

    And then, similarly, CloudBolt can call out into existing tools they’ve got. A lot of our customers have homegrown cloud management or change management databases, CMDBs, and they want CloudBolt at some point in the provisioning process to call into those to register a new server or CI in there.

    Ashley: Mm-hmm. What’s the next thing that’s happening for you with your product and where you’re taking this?

    Sanders: There’s a lot of things that are happening in the cloud management space, you know? The space is not too old, so it’s still defining itself, and the industry is still figuring out what they need in this kind of a tool. So, we have been introducing increased cost management and analytics to show you what your public cloud spend is and what you could save and give you recommendations on how to save. So, that’s a common area of improvement, continuing to make it more and more extensible and consumable, of course, doubling down on our containerization support, we started supporting Kubernetes in 2015 and we’re leveling that up in each of our releases.

    And then, as well as supporting all of the different directions the public cloud providers are going, they’re trying to diverge; we’re trying to provide a common platform. So, that’s a constant challenge for us to solve and it’s a fun one and it’s one the engineering teams thrive off of to give people a common interface with increasingly different underlying technologies.

    Ashley: I can imagine, obviously the more tool support that you provide for Kubernetes to Jenkins or whatever the next iteration of fantastic tools that are used in a DevOps environment, all the better. But also, if you’re solving, “Here’s log aggregation, here’s audit trails, here’s access controls that DevOps teams don’t have to set up,” that would be—and you can do it through a programmatic interface—that’s gonna be a win for them.

    Sanders: Absolutely. Yeah, and security is an increasing focus for us as well, providing tools and integrations through which they can make sure every VM that’s deployed is up to standards and compliance and they can get security reports across their entire enterprise.

    Ashley: Yeah, if you can help them sell through a security audit or review, they’re gonna love you, I would think.

    Sanders: Yes.

    Ashley: We could talk about this for another 40 minutes if we wanted to. Unfortunately, we don’t have that much time. I’d like to thank you, Bernard Sanders from CloudBolt, for joining us.

    Sanders: Thanks, Mitch. It’s been really fun.

    Ashley: And I’d like to thank our listeners, of course, for being with us today. This is Mitch Ashley with devopsy.kinsta.cloud. You’ve listened to another DevOps Chat, and be careful out there.

    — Mitchell Ashley

  • DevOps Chat: Enterprise Multi-Cloud Backbone With Aviatrix

    DevOps Chat: Enterprise Multi-Cloud Backbone With Aviatrix

    Our podcast guest believes the world changed “on a Tuesday” six months ago when the enterprise move to the cloud became imperative, not just an aspirational goal. That eureka moment was enough to pull Steve Mullaney off the sidelines and back into the game as CEO of Aviatrix after successful executive gigs at Palo Alto Networks and Nicira.

    “Go build” might be a wonderful approach for cloud-native apps, but enterprises want the framework laid out ahead of their move to the cloud. Think enterprise cloud IT reference architecture, much like Cisco provided for enterprise IP networks, DEC mainstreamed for client-server and IBM established for mainframe computing. You have to bring the cloud to them. That enterprise cloud reference architecture is what Aviatrix targets, in the same buy-with-a-credit-card model that fueled customers’ unfettered move to AWS.

    On our DevOps Chat podcast episode, Steve Mullaney, CEO of Aviatrix, talks about what enterprises want in a true enterprise multi-cloud backbone to support their needs.

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

    Transcript

    Mitch Ashley: Hi, everyone, this is Mitch Ashley with devopsy.kinsta.cloud, and you’re listening to another DevOps Chat podcast. Today, I’m joined by Steve Mullaney, CEO of Aviatrix. Our topic today is enterprise multi-cloud backbone—meaty, good stuff.

    Steve, welcome to DevOps Chat.

    Steve Mullaney: Thanks for having me, Mitch.

    Ashley: Great, good to have you here. I’d like to start by having you introduce yourself. I know a lot of us know you from your background, you’re a fairly well known guy, but tell us about yourself.

    Mullaney: So, yeah, my name is Steve Mullaney, I’ve been in networking and security infrastructure for, really, the past 35 years. I actually started my career in the mid-80s as we were kind of evolving from, transitioning from the mainframe computing model into client server. I was actually an engineer on 10Base-T from the company called SynOptics. So, those of you who’ve been around long enough to remember when Ethernet was starting and—

    Ashley: I do recall.

    Mullaney: 10Base-T started, yeah. So, I spent most of my career in networking and security, I was a very early guy, actually, also at Palo Alto Networks, I was the first VP of Marketing there, employee number 25. And then was CEO of a company called Nicira, which was really kinda the beginning of a lot of this SDN craze and network virtualization. We were acquired by VMWare, and then I stayed at VMWare for a couple years and grew that business, which is now almost a $2 billion business and a ________ business.

    And then, for the last five years, I just, I kind of said no more operational roles and was on boards and I was content to just do that the rest of my life and very happy living the dream. And I saw the world change about six months ago, where enterprises have been talking about the movement to a cloud computing model—honestly, talking about it for the last 15 years, but I noticed really about 6 months ago is when mainstream enterprise really said, “Okay, we are doing this.” And I just looked at that opportunity and said, “My God.”

    And I was on the board of Aviatrix at the time, so I could see this happening up front and just said, “This is just gonna be too much fun not to be involved.”

    Ashley: So, what was it? What was it six months ago or so? When was the nexus point when you saw a change that pulled you out of retirement?

    Mullaney: Yeah. What was interesting was, I love to say, six months ago on a Tuesday. And it felt almost like that much—like, literally on a Tuesday. And that’s how enterprises move, right? They talk about it, they talk about it, they talk about it, they talk about it. It’s like going on a diet. You talk about it and, “I’m gonna go on a diet.” “Well, how about today?” You’ll say, “Well, you know—not a good day.” “Well, how about tomorrow?” “Well, you gotta start on a Monday,” right? And then, “How about next Monday?” “Well, that doesn’t really work, because I’m going on vacation.”

    I mean, there’s all these excuses, and enterprises, about five years ago, really said, “Alright, we are gonna move to the cloud.” And honestly, that’s when every enterprise vendor went, “[Gasps] We’re dead!” Right? “We’re dead. Everything’s gonna go into Amazon and we’re dead.”

    Ashley: Mm-hmm.

    Mullaney: And what happened was nothing, because the enterprises were just talking. They didn’t really mean it, right? So, everyone went along their merry way with quarter after quarter of record highs. Until about six months ago, I’m on the board of Aviatrix, a bunch of other infrastructure companies and I notice the logos are changing. This isn’t Netflix any more, this isn’t small to medium businesses, these aren’t early adopters. These are Midwest manufacturing, conservative companies. What the heck is goin’ on? They shouldn’t be doing this!

    And people think just because AWS is at a $30 billion run rate that we must have crossed the chasm by now. We haven’t. And I’ve noticed, across all of my infrastructure companies that I was on the board of, they’re seeing all the same thing. No one’s done anything different, it’s just, the market just changed. And the way enterprises go, they are a herd mentality. When the majority, you know, the early and late majority of customers all decide to do something, they all decide on the same Tuesday morning, and I saw that happen.

    We saw it with client server. I was at SynOptics at the time. Mainframe computing was the way you did enterprise computing, and client server—PC client server was treated as a toy, just fun and games. So, print sharing, right? PCs—that’s not real computing, right?

    Ashley: Mm-hmm, mm-hmm.

    Mullaney: And then what happened? All of a sudden, in the early ‘90s, on a Tuesday morning, everybody decides the Internet Protocol is the only protocol that matters. All the other protocols went away overnight, and PC client server is the way I’m gonna build up my architecture—and it happened overnight. I saw the same thing happen with cloud.

    Ashley: Mm-hmm. So, it’s really kinda going mainstream, you’re seeing a real—

    Mullaney: It’s gone mainstream. And I’ve been at the company now for three months as the CEO of Aviatrix and every day, I just see more and more evidence of that, that companies are burning the boat—meaning, the corporate data center, the corporate backbone that is dead. It is now an expense. I view it as an expense, and I view anything I do in the public cloud, leveraging the public cloud, as an investment.

    Ashley: Mm-hmm.

    Mullaney: And that means all my people are focused on that as well as all my expenses. And it shifts overnight, and it’s a herd. Every single enterprise around the world is now making that same decision on the same Tuesday morning.

    Ashley: Mm-hmm. I love your Tuesday morning analogy.

    Mullaney: Isn’t it funny? It’s really true, though—it’s really true!

    Ashley: [Laughter] It just seems like it suddenly happened.

    Mullaney: Yeah.

    Ashley: So, you’re on the board of multiple companies. What was it about Aviatrix that you said, “This is the one I’m gonna ride. This is the one I’m jumping on board, I’m gonna be CEO, take this baby where it’s gonna go”?

    Mullaney: Yeah, I think it goes—because it goes in terms of what we say our mission, our mission is to build the enterprise multi-cloud backbone.

    So, when you look at AWS and Azure and GCP and even AWS’ mantra to enterprise is, “go build.” Well, that’s great when you’re an early adopter and they hand you the power tools, and you—

    Ashley: Mm-hmm, the greenfield.

    Mullaney: Yeah and you are that innovative, you wanna go build. That does not go very well when you’re a Midwest manufacturing, conservative company. I’m gonna cut my arm off with power tools. I don’t want power tools. I want a house, I want furniture, I wanna walk in with it done. I don’t wanna build anything.

    Ashley: I want a landing strip, I don’t wanna build the runway.

    Mullaney: Absolutely. I do not wanna build. And so, I think this, honestly, has caught AWS off guard, too, right? Because they’re thinking—all of our customers love that, a “go build” mantra. Not the mainstream, right? Not when it flips. Not when you’ve crossed the chasm and now you’re in the tornado and everybody just, they’ve gone and said, “This is it.”

    And so, I looked at that, and I said, “My God, all of these enterprises are begging—begging—someone to define the architecture for them.” This is just like in the client server where they needed Cisco to come out and define the networking and security architecture for them. Give me the canonical architecture that everyone’s gonna do, and then I will go implement that.

    Ashley: And it’s proven, we’re not inventing.

    Mullaney: And that’s what people want, and they want a validated design. They wanna be able to go, “This is what everyone’s doing, we’ve all agreed, this is what you do. And oh, by the way, I can’t get that from Amazon, because Amazon’s trying to lock me into Amazon. I can’t do it—I can’t get it from Azure or Google. I can’t get it from the old world, I can’t get it from Cisco, because they don’t even understand this,” right?

    Being able to—it’s just like, you wouldn’t go to IBM or Deck for the client server architecture. This is a whole different computing model. You can’t—by definition, the leaders of the old are never the leaders of the new. So, who do I go to?

    Ashley: Yeah, and to the point of multi-cloud, you’re probably not gonna be in just one, yes? It might be appealing to be in Azure for some Microsoft apps, but you also have compelling reasons to be elsewhere.

    Mullaney: I have not met an enterprise that says they’re only gonna be in one cloud. They’re in at least three. Because then you’ve got, if you’re in China, you’re in Alibaba. Then you’ve got, you know, data sovereignty and GDPR and all these kinda other issues that I may have to have multiple providers in Europe, country by country, right? And not even AWS.

    And so—sure, absolutely, it is going to be, and it should be. Because not that you’re gonna move workloads between one to the other. Like, that’s not gonna happen. But what is gonna happen is, maybe the marketing team likes GCP for AI reasons or, you know, I started with Office 365 in Azure and so I’m moving off on that. Or I’m a big enterprise, manufacturing enterprise and Microsoft really understands me. Or I’m a retail and I will not have anything in AWS, right?

    Ashley: Yeah.

    Mullaney: Or I see, even, I’m a customer, I’m a company—a software company. I’m selling to other enterprises. I cannot have my infrastructure if I’m selling to retail. I cannot even have my own internal infrastructure on AWS because they don’t want that to happen.

    So, absolutely, it has to be across all this. And then the other thing is the “go build” mantra—so, even if you could say, “I can figure out how to go build on AWS,” the constructs in Azure and GCP are different.

    Ashley: Right, you’d have to go build everywhere.

    Mullaney: So, now I need to learn those constructs, and now I have to go build there, but with different tools that work differently—like, one’s in metric and one’s in an American system. It’s like—oh, my God, you know? And the tools don’t work. Like—okay, this is ridiculous.

    Ashley: So, you painted a picture of multiple compelling reasons somebody needs to lay the groundwork for me. I’ve gotta be multi-cloud, so I need that reference architecture that’s gonna work across multiple providers. I don’t wanna stick build any more, I wanna be able to walk in and plug my application into a framework, a reference architecture that I can use—that’s what Aviatrix is about?

    Mullaney: Yes. And then layering on top, leveraging the constructs, right? Leveraging the wonderful underlay, right? Of all—think of all the fiber, and the pops, and the data centers, and the regions, and all the wonderful stuff underneath that AWS Azure and Google provide, and growing.

    Ashley: All that infrastructure you don’t have to do.

    Mullaney: That is unbelievable, right? And guess what? I’m an over the top networking and security software player. So, when you think of guys like WhatsApp, you know, AT&T used to always get really mad because WhatsApp gets bought by Facebook for like 30 billion or whatever it was, and AT&T with all their fiber and all their different pops and all their right of ways and everything else like that—what’s their market cap? I don’t know. Probably not even much more than that. And you go, “Why is that? Like, I do all this stuff and I get no credit.”

    Ashley: Spend a lot more money getting there.

    Mullaney: And then WhatsApp with, you know, six engineers gets bought for $30 billion, where’s that? Well, yeah, because the over the top guys, that’s where all the value is. They’re leveraging it.

    So, in a sense, we are an over the top software player, but what we’re over the top of is not the internet on top of AT&T, it’s the new internet. It’s the hyperscalers. It’s AWS, Azure, Google, et cetera, all with massive bandwidth and the best latencies you can get in peering points to each other such that when we overlay these decoupled security services on top, the combination is an amazing architecture and network.

    Ashley: So, talk about those services. Talk about security operations, extensions, transit—all of those things that you need to take care of, orchestration—how does that work with ABHS?

    Mullaney: Yep. Yeah, so in this what we call the enterprise multi-cloud backbone, there are, you know, today probably seven or eight different services that a customer can start with. And the beautiful thing about this, again, you can use Aviatrix. We have over 300 customers right now and growing rapidly all over the world—customers all over the world. We don’t even know that, because this is low friction land and expand. A real true cloud model where they can actually start. It might be $500 a month. It might be $50 a month. It also could be $3,000 a month. They just start using it, and they might stop with one use case. “Let me try it out.” They get their credit card, it integrates in through AWS Marketplace or the other marketplaces, and all of a sudden, they just start charging. And guess what—next month, they add. Next month, they add. Next month, they add. And then they say, “Oh, I now need additional things,” right?

    So, they may start with a service we call user VPN. So, basically, we take OpenVPN and we add a lot of additional functionality to it, integrating it with SAML and other authentication means, add in some more security controls, and say, “Hey, I’ve got users, and I want them to VPN into the cloud, because I have resources in the cloud. I want them to be able to securely connect them to the cloud.”

    That might be the first use case you start with, and maybe you’re paying $1,000 a month, but from there, it’ll start growing where then you say, “Well, now I need transit networking,” right? Or, “I need egress filtering. So, guess what, I start going into the cloud.” Guess what, most of your VPCs and your resources in the cloud have to access things on the internet for build packages or et cetera, right? Because this is a very distributed, hybrid world. So, it’s not just all inside the cloud. Well, guess what? I wanna do filtering on that outbound, and I wanna do what’s called FQDN, fully qualified domain name, which, I don’t wanna do filtering based on an IP address or let them go anywhere they want. I wanna say, “You can go anywhere, yahoo.com or wherever you need to go for that build package.”

    Ashley: Mm-hmm.

    Mullaney: And that’s it. So you wanna be able to whitelist it, and you wanna be able to define it per user and per VPN. So, you wanna be able to have security policies of who can go where. So, that’s another use.

    Other use case is encryption. You know, right now, people say, “Well, you run”—you know, six months ago, when the cloud was kind of fun and games, “Hey, I’m putting workloads up there, it doesn’t really matter, it’s not my enterprise.” You know, maybe you didn’t worry about encryption. But now, you’re a retail or you’re a bank, you know, and all of a sudden, you care. So, you’re gonna wanna—

    Ashley: Yeah, if you’re gonna put in an enterprise application, you’re gonna miss encryption, security, it’s high [Cross talk].

    Mullaney: Yep, yep. You’re gonna wanna encrypt in flight, right? So, not only do we allow encryption, but we also allow high performance encryption, right, to 10 Gig, 20 Gig, 30 Gig and more, where—you know, and that’s important as people are putting PII data and other things. And also, from a security perspective, people know that—look, I’m just gonna encrypt everything. The data as well as in transit.

    And then, you know, as you talked, being able to do this across multiple clouds, right? So, I maybe can connect, I wanna be able to connect up multiple regions within one of the clouds, but then I also wanna be able to go to the other clouds as well and create one kinda common framework upon what we’re doing.

    And then I’d say another service is what we call firewall network service, and that’s another one, I can talk more specifically about that. But everybody that’s coming to the cloud—again, this isn’t fun and games any more, this is serious business. The first thing they say is what? Security and policy, I need to bring my next generation firewall policies into the cloud with me. And I need—so, if I’m a Palo Alto Networks customer, the first thing I wanna do is, I wanna take my VM series into the cloud. And when I try to do that, the construct of how AWS says you can connect your VM series firewall into AWS forces compromises in performance, scalability and visibility that are just untenable. And, with Aviatrix, we eliminate those trade-offs.

    Ashley: It’s certainly a fundamental component of where you’re gonna start to build out your infrastructure. If you can bring as much of your own network security into the cloud, all the better—that’s your strategy, yeah.

    Mullaney: Yeah. Well, you know, I think what’s important is, and I think guys like Amazon are realizing this, is when you have to deal with, when you’re dealing with the enterprise—and I mean, the enterprise. The Midwest, conservative, classic mainstream enterprise, right? You have to bring the cloud to them. You can’t make them go to the cloud, right? They’re looking at this and they’re saying, “Okay, I’m all in. I’ve burned the boat, I’m gonna get rid of my data centers, I’m all in.” But then they look and they go, “The grass ain’t as green as I thought it really was.”

    Ashley: Mm-hmm.

    Mullaney: There’s a lot of burned out spots, here. This “go build” mantra? Whoa, whoa, whoa, whoa—wait a minute. I thought I was gonna hit a couple clicks and be done. And oh, by the way, CEOs and CIOs of companies, they’re all bought in and said, “Hey, you know, we used to have hundreds of people managing this infrastructure when it was on prem, but I understand cloud. I only need tens now,” right?

    Ashley: Mm-hmm.

    Mullaney: So, the problem is, [Laughter] they go to the cloud, and again, I’m seeing this everywhere, every enterprise said, “We don’t really have enough people.” Like, we got kinda sold a bill of goods, here. Everyone kinda told us this was like click, click, click—you’re done. It ain’t that easy, right? And then you throw across, “Now, I’m gonna do it across multiple clouds—I don’t know how we’re gonna do this.”

    Ashley: Well, let me ask you, then, we’re coming up on the end of our time here, together—if you had one parting recommendation thought for those enterprises that are in that first six months window and really looking at moving to the cloud or are in that process, they wanna check out Aviatrix, they wanna maybe do a prototype or look at the reference, how they build a reference architecture on the platform—how do they get started? What’s the best way to do that?

    Mullaney: I mean, the first thing I always tell people, the best way to get started is actually just get started. The good thing about this modern world is, we don’t have to do a POC. We don’t have to—you can actually get started over the weekend, and that’s how many of our customers start. They just start playing around with our software, like on AWS Marketplace, it’s a great place to start. They just spin up a controller, they spin up a couple gateways, they—and we have quick start guides to show you how to do it in a very easy way. And people start playing with it and they go, “Oh, that’s pretty interesting.”

    And so, they start with kinda one use case, right, and a very small little bit and they effectively do their own little POC. And they say, “Okay, that’s pretty interesting.” Now, we can also do it for them, but that’s a pretty good way to start.

    And then I’d say the other thing is, what you really are gonna look for—I mean, there’s only one reason why people aren’t using Aviatrix right now is because they’ve never heard of us. As soon as they—as soon as we talk to people, they’re sold. Because they look and they go, “This is exactly”—people say, “That’s exactly what I’m looking for. I need someone to help me build out my multi-cloud, my enterprise—my, my, not someone else’s, my enterprise’s multi-cloud backbone, and all these networking and security services that go along with it. That’s what I need, and you guys are doing it for me? That’s exactly what I need.”

    Ashley: Well, great. I thank you so much for being with us. We’ve reached the end of another DevOps Chat podcast. It seems like there’s never enough time. I’d like to thank you, Steve—Steve Mullaney, CEO of Aviatrix for joining us.

    Mullaney: Great.

    Ashley: And thank you, you, to our listeners for joining us also, of course. This is Mitch Ashley with devopsy.kinsta.cloud. You’ve listened to another DevOps Chat. Thanks for joining us.

    — Mitchell Ashley