devopsy.kinsta.cloud

Category: Infrastructure/Networking

Newly Independent VMware to Focus on Multi-Cloud

As an independent company once again, VMware will focus its efforts on providing management planes that span multiple cloud computing environments after officially spinning out of Dell Technologies.

Ray O’Farrell, executive vice president for the cloud-native apps business unit at VMware, said the company now has a unique opportunity to work closely with providers of cloud services, builders of on-premises IT infrastructure and providers of telecommunications services.

The terms of the spin-off included an $11.5 billion special cash dividend that resulted in a $27.40 per share dividend payment to all VMware stockholders. VMware claims the simplified financial structure that arises from the deal will provide it with additional operational and financial flexibility.

Going forward, much of the development work will focus on providing management planes that not only span multiple clouds but also address specific cross-platform requirements such as security. It’s not likely there will ever be one single uber control plane for all of IT, noted O’Farrell. Rather, IT teams should expect VMware to deliver a series of well-integrated control planes to automate specific tasks in a way that breaks down IT silos, he said.

VMware, however, under terms of its existing alliance, will also continue to work closely with Dell to create server environments that are optimized for VMware hypervisor platforms, O’Farrell said.

Key to the strategy is a portfolio of observability tools that VMware plans to continue to expand, noted O’Farrell. VMware will also address the requirements of both traditional monolithic applications running on virtual machines as well as cloud-native applications running on distributions of Kubernetes, such as VMware Tanzu, that may be deployed on top of a hypervisor or on a bare-metal server, he added.

Given the complex state of IT environments today, it’s all but inevitable something will go wrong, said O’Farrell. The challenge and the opportunity for VMware is to provide IT teams with the observability tools required to discover as many issues as possible before they adversely impact the business, he added. Once those issues are discovered, IT teams should be able to automate the remediation process using the rest of the portfolio of VMware management frameworks, he noted.

Those management frameworks will also provide the foundation for unifying traditional approaches to IT service management (ITSM) with DevOps best practices that are now being used more widely, especially to manage cloud-native applications, said O’Farrell.

When it comes to on-premises IT environments, VMware continues to dominate. Its hypervisor is, by far, the most widely used on servers in local data centers. VMware has spent much of the last two years expanding its reach into multiple clouds to enable IT organizations to standardize on a series of management frameworks. The goal is to reduce the total cost of IT by reducing reliance on what would otherwise be a hodgepodge of isolated management frameworks. The challenge VMware regularly encounters is the IT teams that manage cloud computing environments are not always the same ones that are managing on-premises IT environments. As such, many IT teams that have deployed cloud applications tend to embrace the management frameworks provided by their cloud services provider.

VMware, however, is betting that as more organizations look to reduce the total cost of IT, the economic pressure to converge IT management using its frameworks will be simply too great to ignore.

November 2, 2021
Intel Woos DevOps Teams with API and Processor Advances

During the online Intel Innovation 2021 event, Intel announced today a unified Developer Zone for accessing application programming interfaces (APIs) that it makes available via a oneAPI toolkit to IT teams that want to more easily invoke a wide range of processor types and classes.

At the same time, the company also revealed it is creating a set of oneAPI centers of excellence that will make it easier for DevOps teams to consume those APIs. Partners participating in that initiative include Oak Ridge National Laboratory, University of California Berkeley, University of Durham and University of Tennessee. Intel will also make the Intel Graphics Visualization Institutes of Xellence part of this program.

Next year, Intel is also promising to deliver oneAPI 2022 toolkits that will add 900 additional capabilities including an ability to develop applications for CPUs and graphical processor units using what Intel described as the first unified C++/SYCL/Fortran compiler.

The company is also planning on making available Data Parallel Python tools in addition to expanding its Advisor accelerator performance modeling tools to include support for VTune Flame Graph to visualize performance hot spots.

There will also be additional oneAPI integrations to add support for Microsoft Visual Studio Code and the Microsoft Windows Subsystem for Linux 2 platform. Intel also created an Intel oneAPI AI Analytics toolkit to enable out-of-the-box AI development that is supported by workstations running Linux from Dell Technologies, HP and Lenovo. Additionally, Microsoft and Intel have agreed to create a complete data science toolchain to Windows 11 that will become part of the Surface Laptop Studio framework for building applications.

Greg Lavender, chief technology officer, senior vice president and general manager of the software and advanced technology group at Intel, said it’s critical to make sure that DevOps teams add support for the acceleration engine and extensions that Intel makes available within its processors to the runtime environments they deploy. Otherwise, developers will never be able to routinely invoke those capabilities to build next-generation applications.

The company also revealed that next-generation Intel Xeon Scalable Processors, code-named Sapphire Rapids, will have additional acceleration engines to both simplify deployments at scale and optimize processors’ core utilization in a way that reduces power consumption. Overall, Intel is promising up to a 30x total performance gain for artificial intelligence (AI) applications running on these processors.

Other hardware advances announced today include a 12th generation Intel Core family based on 7-nanometer processors and a Mount Evans project through which Intel is collaborating with Google Cloud to build processors based on application-specific integrated circuit (ASIC) chips.

The company also unveiled an Intel ArcTM Alchemist family of graphics systems on chips (SoCs) that take advantage of machine learning algorithms to optimize performance and touted an Intel Tofino fabric processor (IFP) that adds intelligence to network switching via support for P4 programming tools.

Finally, the company noted that an Aurora supercomputer, due out in 2022, will exceed two exaflops of peak double-precision compute performance.

As Intel seeks to regain the processor high ground from rivals such as NVIDIA, ARM and AMD, it’s clear that the future of IT will be defined by a broad range of processor classes that all have unique capabilities. The challenge now is deciding which of those capabilities to actually make available to developers that are largely dependent on the runtime environment that DevOps teams decide to make available.

October 27, 2021
Defining Availability, Maintainability and Reliability in SRE

In the world of reliability engineering, you’ll frequently encounter the three “-ability” words: Availability, maintainability and reliability. They sound similar and have similar meanings. In fact, these words may seem so similar that it can be tempting to use them interchangeably.

That would be a mistake. Availability, maintainability and reliability all have distinct—if related—meanings, and they each play different roles in reliability operations.

Definitions of Availability, Maintainability and Reliability

Let’s start by succinctly defining each of the terms.

Availability, Defined

Availability is the extent to which an IT resource is ready to perform a task when requested.

Thus, an application or server that is responding to requests is available (even if it takes longer to respond than desired or otherwise operates suboptimally, in which case it may have a reliability issue but not an availability issue).

Availability is usually measured as a percentage. A resource that has 99% availability, for example, is one that is up and responding 99% of the time.

Maintainability, Defined

Maintainability is a measure of how quickly and easily a resource can be fixed when something goes wrong.

If a buggy application release can be quickly fixed by rolling back to a stable version, the application would have a high degree of maintainability. On the other hand, if you have a server that needs to be rebuilt manually after it fails, it’s not very maintainable.

Reliability, Defined

Reliability is the extent to which a resource functions as required upon request (as opposed to simply being available).

For example, if your users require an application to process each transaction within one second, and it does this 99%of the time while also maintaining a 99% availability level, that would be a relatively reliable application. In contrast, an application that responds to almost all requests but that suffers from high latency or error rates would not be very reliable, although it might be highly available.

Differences Between Availability, Maintainability and Reliability

The simplest way to spell out the differences between availability, maintainability and reliability is to highlight what’s unique about each concept.

Availability

Unlike maintainability and reliability, availability is an essentially binary metric, in the sense that a system is either available or it’s not. Although availability status can change over time, there is no such thing as varying degrees of availability.

Availability also stands out because it is often the most important metric in defining SLAs and SLOs. Contracts typically specify that resources will achieve a certain level of availability, defined in percentage terms. They may sometimes also specify metrics like response times, which are a reflection of reliability, but availability is more likely to be the most important metric within service agreements.

Maintainability

Maintainability is unique in that it’s a pretty subjective concept. A system that one SRE considers easy to maintain could seem difficult to maintain to another SRE. The methodologies that engineers leverage to optimize maintainability could vary, too; for instance, someone from a DevOps background may be more likely to focus on optimizing maintainability within the software delivery chain than someone trained in classic site reliability engineering, which focuses on automating IT operations through code more than on the software delivery process.

That said, automation tools help virtually every team maximize maintainability, no matter their preferences or background.

Reliability

Reliability stands out because it reflects how well a system performs. Here again, this is a somewhat subjective metric, because performance requirements may vary from one user to another. Nonetheless, reliability is the most effective means of measuring whether a system meets the performance levels it needs to, even if those requirements change over time.

Why do availability, maintainability and reliability matter?

Because availability, maintainability and reliability each measure different aspects of a system’s status, putting them together is a useful means of gaining insight into the overall reliability of a system.

In order to be reliable, a system requires both availability and maintainability. A system can’t be reliable if it’s not available. It’s also unlikely to be highly reliable if it takes a long time to fix issues due to low maintainability.

At the same time, by focusing on availability, maintainability and reliability individually, you can drill down into specific issues within the IT resources you manage. For instance, you might have systems that are high-performing when they’re available, but that have low reliability rates because of availability issues. In that case, you’ll know that an investment in increased availability is likely to yield the greatest reward for increasing overall reliability.

The Bottom Line

The bottom line: While availability, maintainability and reliability are all reflections of the quality of an IT resource, they measure quality in different ways. Tracking each category separately is important for ensuring that you know where your weakest links exist within overall system performance and health.

At the same time, however, it’s important to compare and correlate availability, maintainability and reliability data so that you can achieve continuous insight into a resource’s status. When you can track each item separately but also combine them together to gain a complete picture of your system, you are in the best position to optimize reliability operations.

October 25, 2021
Energy Efficiency and the Data Center

The IT industry has historically been a leader in the ongoing race to reduce CO2 emissions. Reducing emissions is good for the environment and for the corporate bottom line. The data center is well-known as a voracious data consumer. But the data center consumption findings keep pace with the trend. Even in the face of remarkable growth in data center capacity and performance, their energy consumption has increased only a few percentage points since the 2010s. This almost-flat rate of energy consumption is primarily the result of the shift to cloud computing as well as the shift to solar and wind energy, where it makes sense.

Investments in renewable energy sources have helped tamp down criticism over the overall IT carbon footprint. Knowing that it takes a tremendous amount of energy to power a data center, owners and operators are always looking for ways to improve efficiency and reduce carbon expenditure. Today, there are newer and better ways for organizations to deliver the performance to properly power modern applications while keeping in mind the energy efficiency and carbon reduction the world requires.

Minimizing Energy Use and CO2 Production

How did we get here? Decades of semiconductor process miniaturization in concurrence with living out Moore’s Law has culminated in ongoing improvements in performance, storage capacity and device density. Today’s mobile phones are a great example of that ongoing progress. A secondary factor in the mobile phone revolution is a processor architecture optimized for efficiency and flexibility. This ARM architecture has been used to power almost all devices since the first iPhone. Over the years, ARM has also become a realistic platform for servers; often a better choice than an x86 system.

Energy efficiency is one area where ARM systems win out over conventional server architecture. But it was not until recently that ARM processors could deliver the required performance for the data center. Today’s systems, based on Armv8 designs, have brought into play x86-class capabilities in a more energy-efficient way. The advent of the ARM-based AWS Graviton processors, which by some estimates have already captured 20% of the instance share on AWS, demonstrates that ARM can run production workloads while delivering what AWS calls “up to 40% better price performance over comparable current-generation x86-based instances for a wide variety of workloads.”

To illustrate the impact on carbon production when a data center shifts from x86-based architecture to ARM servers, an analysis of the top elements contributing to data center energy use was undertaken. The energy savings was calculated and translated to reduced CO2 emissions based on the fuel mix used to power the electric grid in various locations. The results prove that an ARM-powered data center reduces CO2 production by 74%, equivalent to almost half a million barrels of oil.

Power Consumption Reduced by Efficient Servers

The premise is simple—innovative server design significantly reduces data center energy use. In this model, a server’s power draw and physical size are key factors. The energy needed for other data center subsystems was extrapolated by using ratios derived from experience and validated by estimates from other data center operators.

Data center energy use can be divided into five categories of equipment and infrastructure: Servers, network communications, power supplies, conversion and UPS, cooling systems and storage. Servers and cooling comprise about 75% of the total.
The calculations were based on the energy used by a medium-sized data center with 750 racks of conventional 1U servers (42 servers/rack; around 31,500 in total). Assumptions used included servers comprising two-thirds of the floor space and that the equipment space accounts for 65% of the total, translating to a 62,000 square-foot data center. For comparison, facilities operated by the major cloud vendors can be a million square feet or more. Knowing server power consumption and the ratios for the equipment categories, algebra can be used to calculate the energy consumption for each.

The data center in this hypothetical example has, as we said, 31,500 servers. Using the 912.5W power draw of a Dell R640 as typical of 1U x86 servers, the total server usage in the ARM data center would be 251,795 MWh/year. Using this formula, the amount of energy saved by using ARM servers can be calculated. Each server requires about one-quarter the electricity of a standard server. In the formula, the assumption is that the ARM server installation would require half the equipment racks (375 instead of 750) and 52% of the power-per-system, comprising a data center using only 26% as much electricity (152,409 MWh/year) as one based on x86 systems.

The math shows that switching one medium-sized data center to ARM servers can produce annual savings equivalent to 45,459 fewer cars on the road or 486,749 fewer barrels of oil used.

The value in CO2 reduction is widely understood for preserving the environment. It is also advantageous from an economic standpoint. In fact, there are many technical and economic reasons to adopt energy-efficient ARM-powered servers in the next-generation cloud data center.

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

October 15, 2021
CNCF Adopts Meshery to Advance Service Mesh Management

The Cloud Native Computing Foundation (CNCF) announced this week during the ServiceMeshCon/KubeCon + CloudNativeCon conference that Meshery, a service mesh management plane created by Layer5, has become a sandbox-level project.

In addition, Layer5 has also donated Service Mesh Performance (SMP), a set of tools for measuring the efficiency of a service mesh, to the CNCF. SMP provides an open source framework to define standardized benchmarking practices, performance test configurations and measurements as part of an effort to create a MeshMark index for rating a service mesh. A set of service mesh performance methodologies will also be published by the IEEE later this month, developed in collaboration with engineers from Layer5, Intel, Red Hat and HashiCorp.

Layer5 CEO Lee Calcote said the goal is to make it simpler for IT teams to determine which service mesh to employ based on their specific use case requirements.

Several service mesh platforms are starting to gain traction as a means to both manage application programming interfaces (APIs) and provide a layer of abstraction between lower-level networking and security APIs that makes those services more programmatically accessible to developers.

Meshery itself is an implementation of SMP and the conformance tool created for the Service Mesh Interface (SMI), a separate CNCF project to promote interoperability between service meshes. Meshery is based on a set of microservices that are designed to make the platform easily extensible.

That approach makes it possible to manage multiple instances of service meshes that might be deployed on virtual machines as well as Kubernetes clusters using a range of management tools that are part of the Meshery project.

Meshery supports AWS App Mesh, Citrix Service Mesh, HashiCorp Consul, Istio, Kuma, Linkerd, Network Service Mesh, NGINX Service Mesh, Open Service Mesh and Traefik Mesh. Meshery also provides IT teams with more than 60+ best practices in the form of templates that can be used to deploy a service mesh.

It’s still early days as far as adoption of service mesh in the enterprise is concerned. Most IT teams still rely on either proxy software or a gateway to manage APIs. However, as the number of APIs that need to be managed steadily increases, it won’t be long before many IT teams start to at least evaluate a service mesh.

In the longer term, the impact those service meshes are likely to have on the management of IT could be profound. It is becoming apparent that a service mesh also provides a higher level of abstraction for invoking networking and security services. In fact, the service mesh may wind up playing a key role in driving the convergence of network and security operations with DevOps best practices.

In the meantime, IT teams will need to decide to what degree they may want to standardize on a single service mesh versus letting individual teams implement their own preferred platform that could one day be centrally managed via Mashery. One way or another, the way APIs are managed and invoked will soon fundamentally change forever.

October 14, 2021
Top 5 Must-Haves for IaC Automation Tools

These days, there are a lot of different DevOps tools to accomplish a lot of different jobs. Almost daily another startup comes out with a new and innovative product or a newer (maybe even better) version of existing tools. One of the biggest innovations has been infrastructure-as-code (IaC). Giving infrastructure admins and developers alike the ability to create, manipulate and destroy infrastructure using code files changes the way we administer our environments. Though these tools are revolutionary and can solve many problems, sometimes they come with a whole new set of issues—as can any type of tooling, really.

Generally, IaC tools are run locally at first. When an infrastructure admin or developer is just starting out with it, they store the files locally; maybe in a repository, then clone the files to execute locally. This is perfectly acceptable and a very common practice. The issues arise when it comes to scaling this practice to a team; for example, with regard to visibility and governance. If everyone is running their deployments locally, the team doesn’t have clear visibility into who is deploying what, when and with what variables. This is where IaC automation tools come into play.

There are many different types of tools to solve these problems. Some are better than others. CI/CD pipeline tools, custom-built automation platforms, purpose-built IaC automation platforms—each has their pros and cons. Getting into all of that can be overwhelming and we could go on for hours about each option. But, we’re here to talk a bit more generically today. So, we’ll save all of that for another time. For now, let’s take a step back and talk about the top five must-haves for any infrastructure-as-code automation platform you’re considering. Because each company and use case is different, we’ll talk about these considerations in no particular order.

Role-Based Access Control (RBAC)

This first factor is pretty important. I know I said I wasn’t discussing these in any real order, but this one should really be close to the top of the list for anyone looking into IaC automation. We talked about how automating IaC can cause visibility issues when you scale across a team. You may want to know who deployed what, when, where and why, for example. Usually, the reason you want that kind of visibility is that you would like to control all of these aspects. That way you can help limit waste, budget problems, security concerns and the like. You may want to provide self-service deployment access, but only within certain parameters; maybe only to certain people or teams. Having granular RBAC can help you design a security policy that makes the most sense for your organization and its needs. Some tools have this baked in, some take a bit of work to make it work. The point is that you should have some form of control over your deployment process.

Self-Hosted Agents/Runners

Following the security thread: A lot of these IaC automation tools are SaaS platforms. SaaS can be very secure. But sometimes, for compliance or regulatory reasons, you may want to retain a bit more control over your deployments. This is where self-hosted agents or runners come in. This type of design allows you to keep your “secrets”—such as your cloud credentials and other sensitive variable information—secure in your own way. You can use whatever secrets management solution you want, be it something from your cloud provider or another third-party solution. It also allows you to keep your code secure. All of these tools, when deploying your code, have to get a copy of that code to deploy. So, they’ll do a ‘Git clone’ or some kind of file copy process to get your files from where they are stored, to execute them. If this is a SaaS solution, then they will essentially have access to your code. Again, this may not be a huge issue for some, but it very much is for others. If you don’t want to give a third party this level of access to your code and secrets, a self-hosted agent or runner can help keep it all secure and under your control.

Plan on Pull Request

This feature is a big one when it comes to workflow. Some may not even know how important plan on pull request (PR) is until they realize how easy it can make their life. This feature may be called something different depending on the platform. Plan on PR, PR plan, speculative plan, etc. Essentially, this means that whenever you open a pull request against a branch, your automation platform will complete a deployment just up to the “plan” phase so that you can see exactly what this code change will do. For example, if you accidentally add an extra 0 to a variable or code file, you may end up with 100 instances instead of 10. Ideally, you’d like to know what was going to happen with a change before it is deployed, giving you the option to quickly fix a potential mistake before it actually goes through. In DevOps, you always want to ‘fail faster’ and close the loop so that big mistakes are caught before they happen. That is why this feature is so important. And if the automation platform you choose is doing this correctly, when it runs this plan phase it’ll automatically update the pull request directly with the possible changes as a comment. This way, your developers can see what is going to happen before they try to merge the deployment back to the main branch for deployment to production. And if they take it a step further by adding service checks to the pull request, you can even configure it so that if the deployment plan fails for any reason, developers are actually blocked entirely from merging the PR back until it is resolved. All of these features help to enable the ability to work in a GitOps methodology. Don’t get me started on the wildl misuse of the term GitOps—it is very specific. While one of the central pillars of GitOps is using your repository as your “single source of truth” for what should be deployed, it’s not just using Git to store your Terraform files; it is an infrastructure administration via pull request methodology. If you want more information about GitOps, you can read more here.

Continuous Deployment

This feature is essential for most folks. But, depending on the workflow, it can be less important. Even if it isn’t a must-have now, it may be down the road when you evolve and grow into new workflows. Continuous deployment is the ability for your automation platform to have a webhook or other connection to your source code repository so that it can automatically trigger a deployment process whenever you commit or push to the repository. This feature goes hand-in-hand with the plan pull request feature we just spoke about. To make that feature function properly, a CD feature would be needed, as well. Now, I want to make sure I clarify. Just because you have continuous deployment enabled doesn’t mean it is just going to push to production in the middle of the day every time a commit or push is done. You should still be given the ability to pause the deployment process after the plan phase. This way you can validate that the plan looks acceptable before you approve the deployment. For some use cases, like developer sandboxes, you may “auto-approve” the deployments because you don’t care about having to get validation first. It all depends on your workflow and processes. A good platform will give you the ability to control all of this.

Shift Left Extensibility

This one is a bit of a wild card. It can mean a lot of different things depending on the situation. Essentially, what I am talking about here is the ability to integrate—or at least be interoperable—with a multitude of other tools during the deployment process. There is a concept called continuous verification which means to shift some tools and processes left into the deployment process so that you can stay on top of problems before they start. In the PR plan feature section earlier, we talked about catching issues before deploying. This isn’t just for resource configuration issues. What about security issues? Compliance issues? Performance issues? Or even budget issues? If your IaC automation tool gives you the ability to integrate the processes and tools you are using to validate these things into the deployment process, they no longer have to be an afterthought. You never have to worry about going over budget if you are constantly validating the budget each time you deploy. You don’t have to worry about a security issue if you’re validating security during every deployment. This type of functionality can look and be named very differently between tools. But as long as you have the ability to get all of these other groups (security, finance, etc.) involved sooner, everyone will be better off. Like we talked about before, in DevOps, it’s always better to fail faster. And integrating these checks into your deployments can help you achieve this.

Conclusion

We’ve made it through all five! We’ve talked about some basic security features. We talked about some automation workflow must-haves to make your life easier. And we even scratched the surface on some next-step-type things to look into such as continuous verification. That was a lot—hopefully this has been helpful for anyone looking into IaC automation platforms and you now have an idea what to look for. Some features may be named differently, but the ideas behind them are the same. If your platform can’t do these, it may not be the right one for you. Or, maybe it is and that feature just isn’t that important to you. As I mentioned, your mileage may vary. Every organization is different.

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

October 14, 2021
The Inevitability of Multi-Cloud-Native Apps

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

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

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

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

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

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

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

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

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

Don’t take my word for it.

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

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

The Enterprise Solution: Planet-Scale Cluster Manager

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

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

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

October 12, 2021
LF Networking (LFN) Adds to Open Source Portfolio

At the online Open Networking & Edge Summit + Kubernetes on Edge Day event LF Networking (LFN), an arm of the Linux Foundation focused on networking, today added several projects that promise to make it simpler to programmatically manage networking services based on open source software.

Walmart is contributing a L3AF project for managing network applications that make use of an extended Berkeley Packet Filter (eBPF) capability that allows applications to run in a sandbox at the microkernel level of an operating system. Intel and Aarna Networks, meanwhile, are donating the seed code from an EMCO project that provides a universal control plane to securely connect and deploy workloads across distributed computing environments that span everything from the edge to the cloud.

Arpit Joshipura, general manager for networking, edge and internet of things (IoT) for the Linux Foundation, said the L3AF project adds a control plane for managing those applications to the LFN portfolio that addresses load balancing, rate limiting, traffic mirroring, flow exporter, packet manipulation, performance tuning and other management tasks. Earlier this year, the Linux Foundation set up a separate eBPF Foundation to further advance development and adoption of eBPF across multiple operating systems.

At the same time, LFN also revealed today that Project Alvarium, a tool for measuring how well data is being delivered to devices that was originally created by Dell, and eKuiper, an existing open source lightweight IoT data analytics and streaming platform, are now part of the LF EDGE portfolio of projects.

Finally, an open source mobile edge computing project, dubbed Edge Gallery, that was originally created by Huawei has been contributed to the Linux Foundation.

Joshipura said the LFN continues to gain momentum as more vendors contribute core technologies that, ultimately, don’t provide them with enough differentiated value to continue to develop on their own. The LFN today also revealed that VMware and F5 Networks have joined the LF EDGE consortium as premier members, while mimik and Veena, Inc. have become general members of LFN and the Eclipse Foundation has become an associate member.

The LFN also provides a mechanism that promotes adoption of those technologies more widely than any one vendor can achieve on its own. The total cost of delivering next-generation edge computing platforms based on wireless 5G networks will also be sharply reduced as LFN projects continue to mature, said Joshipura.

In general, the rate at which various LFN projects are updated continues to accelerate, said Joshipura. The Akraino project for creating blueprints for edge computing platforms recently delivered its fifth update to address use cases involving smart cities, cloud-native multi-tenant environments and vehicular networks. An EdgeX Foundry project for IoT platforms, meanwhile, recently revamped its application programming interfaces (APIs) to make them more secure and enable more message-based communications. The Home Edge project will also soon issue a Drewberries update that will address code stabilization, scripting, APIs, data synchronization and security.

It’s now only a matter of time before these LFN projects become more integrated with DevOps workflows as IT teams seek to give developers more programmatic control over network services. The issue now is deciding not so much whether to integrate network operations and DevOps teams but rather determining to what degree those teams will need to fold into each other.

October 11, 2021
Closing the Education Gap for IoT Developers
The most common thing I hear from developers who are building internet of things (IoT) solutions is: It isn’t easy. And it’s not. Not because of a lack of skill—the developers I interact with are incredibly talented. There’s also no shortage of technologies to choose from for deploying an IoT solution. The challenge often comes down to a gap in available educational materials and learning support when in the development phase.

We’ve moved from the early stages of the IoT when there was a lot of talk but not a lot of application. Now, we’re coming into the “reality phase” where cheaper, large-scale IoT solutions are feasible. In this phase, developers are tasked with identifying, building and deploying technologies that they’re likely having to figure out as they go. It’s a tall order to expect today’s developers to know the ins and outs of all of the moving pieces required for an IoT solution, including the wireless technologies that help to enable them.

While developers are renowned for being effective at independent learning, they still need better access to educational resources and tools when it comes to IoT technologies. This is especially true for newer technologies that you won’t yet find in a textbook or college course.

One example of this newer IoT technology is low-power, wide area networks (LPWAN)—specifically using the LoRaWAN standard. It’s an area that I not only expect to become increasingly relevant for IoT developers but also one that can greatly benefit from more robust educational resources.

IoT Development Is Relatively New

Modern LPWAN technologies have only been around for the past decade, and LoRaWAN became an open standard when the LoRa Alliance was formed in 2015. In the grand scheme of things, that’s pretty new. It’s not a concept that’s widely included in higher education curricula and, although we see more inclusion each year, it can be difficult for developers to find peers who have experience in building with LoRa devices.

ABI Research forecasts that by 2026, LoRa will be the leading non-cellular LPWAN technology. This means that over the next five years more and more developers will need to understand the basics of LoRaWAN but may not have foundational knowledge or experience to draw from.

From what I’ve seen, that gap can lead to teams biting off more than they can chew. Without enough training or support, developers risk building LoRaWAN deployments that may have inadequate coverage or go over scope or budget or that simply don’t live up to their vision.

Complexity in Developing With IoT

The other major reason IoT technologies operating with LoRaWAN need more robust educational support is due to their complexity. Developing an IoT solution requires several different skillsets that well-equipped teams either have to account for in their staffing or—as happens in many cases—rely on a single developer to figure it out and wear many hats.

There are many aspects to building and deploying a LoRaWAN solution; for instance: Hardware engineering, device stack choice and application fit, gateway deployments and networking coverage, cloud considerations and application development involved for deployment. That’s a lot of moving parts.

So, if enterprises and IoT vendors are expecting developers to make large-scale IoT deployments a reality, we have to provide the proper resources and training.

Resources and Communities for LoRa Developers

As the industry works on ways to better educate developers about LoRa technology, there are some good places to start for developers who want to hit the ground running. Here are some resources where you can learn the basics, build prototypes, get advice from other developers and test and certify solutions.
- LoRa Developer Portal—A hub where IoT developers can learn, connect with peers and accelerate their builds with resources like tutorials, dev kits and a free network server. Helpful for every level of expertise, from learning the basics of LoRaWAN to creating a network to rolling out a full-scale commercial solution.
- LoRa Alliance—A nonprofit association where members collaborate and share experiences working with the LoRaWAN standard. They offers events, webinars, a resource hub and more.
- LoRa Basics Station —A GitHub Repository for the open source software that runs on gateways operating with the LoRaWAN standard.
- AWS IoT Core for LoRaWAN—A guide for AWS IoT developers, spanning coverage development and deployment from connecting gateways to monitoring and logging.
- Azure IoT Hub—Guide for connecting the ChirpStack open source network server using LoRaWAN to the Azure IoT Hub.
I expect higher education institutions to begin further integrating LoRaWAN into their curricula over the next several years, which will help to fill the education gap for the next wave of developers. At the same time, IoT vendors can step up and provide additional support to developers who are learning how to build with technologies like LoRa for the first time. This is critical for the success of large-scale deployments that all of us IoT believers hope to see across enterprise environments, cities, regions and beyond.
October 11, 2021
Your Tech is Only as Good as Your Infrastructure

A few weeks ago, one of my neighbors dug a ditch in his yard, hit a fiber internet line and knocked out my internet for eight hours. There I was, ready to start working, and I was cut off from my colleagues for an entire day.

That experience highlighted the importance of a good digital infrastructure—both at the office and at home—particularly as the pandemic has ushered in a hybrid work model. When the pandemic hit, organizations that were agile and had a strong digital infrastructure (including processes) were better able to quickly shift to remote work. Those that were not as digitally mature were forced to adapt.

Eighteen months later, it’s clear that the hybrid model is here to stay, making it even more vital that organizations ensure their workers have the right tech tools to work effectively—and it all begins with a strong digital infrastructure.

Just Because it’s On a Screen Doesn’t Make it Digital

Let’s begin with a definition of digital. I recently had a conversation with a business owner who proudly proclaimed, “We’re digital now.” In actuality, all he had done was put a PDF form on an iPad. Once his clients filled out the PDF, he still printed it and put it in a paper folder. That’s what I call an immature vision of digital, and it’s an extreme example of the ambiguity that often exists around the concept of digital transformation.

It’s not that paper is anathema to digital processes; in some industries (health care, for example) we want paper as a backup. For instance, if I’m a physician at your bedside and the power and/or Wi-Fi goes out and I can’t access your digital records, I need to be able to look at your chart and treat you. So there is a need for paper. But when considering the hybrid or remote work environment, the goal should be to move processes online.

Digital Infrastructure is the Key to Agility

As noted earlier, agile businesses are better able to adapt to changes like the move to a hybrid work model. Agile simply means the ability to move quickly and easily, the ability to move fast and make decisions in a fluid way. To do this, we must remove unnecessary steps so we’re able to focus on the end goal and the essential parts of the process.

This is where a strong (and reliable) digital infrastructure comes in. When you think about Maslow’s hierarchy of needs for digital infrastructure, the foundation is electricity and the internet, and then you build on that. I need computers and hardware and a network, and then I need software platforms and then I need an end-user interface.

But we’re getting ahead of ourselves; let’s go back to the basics. Once we have reliable electricity and internet, we need to look at other technology that can benefit the remote worker, like upgraded microphones and cameras for all those Zoom meetings.

These upgrades shouldn’t be an afterthought on the part of organizations; they are at the center of their employees’ hybrid experience and can be another key to success. It’s not enough to send employees home with a laptop and a monitor anymore. Employers must focus on ergonomics (standing desks, good chairs) and the hardware their employees need to be effective at home. If the employer doesn’t provide them directly, they might consider offering a stipend for employees to make the upgrades themselves.

(Organizations might even consider providing generators to workers who live in rural areas. I have one at my house. And once satellite internet service comes to my town, I’ll have a much more reliable digital infrastructure.)

Now we can start building on that infrastructure. Start with audio and video communication (Zoom, Teams, Dialpad). Then add chat (Slack, Google Chat) and a good customer relationship management (CRM) system (Salesforce, HubSpot). Where does your data live? Having a great CRM system is critical.

Using Digital to Put People First

Organizations ignore the importance of digital infrastructure at their peril. Not only are the days long-gone when employees stayed with a company for 30 or 40 years, but we’re now in the midst of the Great Resignation, where workers are leaving their positions in droves. So it’s incumbent upon organizations to listen to their employees and give them what they need to be successful in a hybrid environment.

And we’re not just talking about tech. Organizations need to keep employees engaged to really understand the pulse that’s around the organization because, as we all know, the culture and tone of an organization can go ebb and flow. It’s critical for organizations to really listen to what employees are asking for and to be flexible so that they can react and adapt to changing times.

If they don’t, a ruptured internet cable may be the least of their worries.

October 8, 2021