devopsy.kinsta.cloud

Category: Cloud Management

  • Cosmonic Unveils PaaS for Building Wasm Applications

    Cosmonic Unveils PaaS for Building Wasm Applications

    Cosmonic today at the KubeCon + CloudNativeCon North America conference unveiled a platform-as-a-service (PaaS) environment for building cloud-native applications using Web Assembly.

    Based on the open source wasmCloud distributed computing environment now being advanced under the auspices of the Cloud Native Computing Foundation (CNCF), the Cosmonic PaaS gives developers access to a lightweight environment that makes it simpler to quickly build applications that can run anywhere.

    Cosmonic CEO Liam Randall said a PaaS enables developers to achieve that goal by making databases and other non-functional services available via an abstraction layer that eliminates the need for developers to provision these resources themselves.

    Designed to be deployed on any cloud service or on-premises IT environment, the Cosmonic PaaS also enables developers to define their own laptops, cloud resources or entire data center by combing resources to create Constellations. Cosmonic also enables developers to build a Super Constellation by adding customer-hosted components to the services provided by Cosmonic.

    Originally developed under the auspices of the World Wide Web Consortium (W3C) for building browser applications, Wasm is a portable binary instruction format for building software that describes a memory-safe, sandboxed execution environment. The wasmCloud project was created by Cosmonic to provide an open source application runtime that hosts components, written as Wasm modules, that can then be loosely connected to build applications. Cosmonic reports there are now more than 100 members of the wasmCloud community.

    The Cosmonic PaaS extends the capabilities provided by wasmCloud so developers can now more easily build Wasm applications via an abstraction layer defined by Cosmonic. Those applications are also more secure than applications built using previous software artifacts because all Wasm code is executed in a stateless and reactive sandbox that prevents malware from moving from one software component to another.

    It may be some time before Wasm becomes the preferred artifact for building applications, but it’s clear the walls that have separated one IT platform from another are about to crumble. Every earlier format for building applications locked developers into a specific platform. Wasm is the first software artifact that enables applications to run on any platform, including Linux and Windows, without any modification required.

    Once applications become much more portable, the longstanding goal of writing an application once and then deploying it anywhere may finally be achieved. Just as importantly, those applications will run in a memory-safe sandbox that is more secure than what can be enabled in legacy IT platforms. In fact, as more organizations review the security of their software supply chains, they may decide to accelerate their embrace of Wasm to build more secure applications.

    Obviously, Wasm has major implications for DevOps teams, and Randall said Cosmonic is working toward integrating its PaaS with multiple continuous integration/continuous delivery (CI/CD) platforms.

    It’s not clear how quickly Wasm will drive a transition to another era of computing, but the ramifications for how IT is managed in the next era of cloud-native computing could be profound. It remains to be seen how quickly developers are willing to embrace yet another software artifact for building and deploying applications. What is clear is that there are an increasing number of platforms that will make it possible to more easily embrace Wasm.

  • When the Cloud and the Edge Are the Same Thing

    When the Cloud and the Edge Are the Same Thing

    Edge computing remains a growing and exciting new architecture for enterprises across multiple industries. Distributing computing power across a decentralized network gives new opportunities for AI- and IoT-based applications. Demand is such that Gartner predicts by 2025, 75% of enterprise-generated data will be created and processed on the edge. 

    However, the cost and latency of sending all this data back to the cloud for processing are significant. To retain profitability, enterprises will need to keep as much data on the edge as possible while also moving processing to the edge. The benefits of these requirements are many, including:

    • Real-time processing, lower latency, faster answers
    • Resilience and availability, not relying on a stable connection to the cloud
    • More resource- and cost-efficient, less data shipping

    I believe organizations achieve these requirements and realize these benefits via a concept I call the cloud-to-edge data plane.

    A cloud-to-edge data plane unifies cloud and edge into a single solution that allows you to define your data and business logic once, package it up as a service and simply deploy it without having to worry if it should run in the cloud or out at the edge (which might change over time). This frees up the data plane automatically and adaptively to move services around, optimizing data access, coordination and replication, ensuring physical co-location of data, compute and user for the lowest possible latency with the highest throughput and availability.

    Choosing between cloud and edge is not a binary, black-and-white decision but has a lot of shades of gray in between. From an architectural perspective, the edge consists of many hierarchical layers between the cloud and the devices; each layer is further away from the cloud but closer to the end-users—a continuum. 

    Where you need your services to run in this continuum is very much use-case-dependent and might change over the lifetime of an application, depending on usage patterns or changes in features and business requirements. Critical parameters like latency, throughput, consistency, availability, scalability, compute resources, etc. change drastically as you move through this continuum. This results in both new opportunities and challenges:

    edge cloud

    One of the new services enabled by this architecture is mobile location transparent services. This new class of services is a thing of beauty. It means services are free to run anywhere and collaborate with other services without restrictions. It also allows the underlying platform to optimize overall system behavior by relocating services as needed, based on changes in usage, resources available, communication patterns, failure scenarios, and more. 

    If services are not location-transparent, then the system’s runtime topology needs to be part of the design and encoded into the services themselves. In practice, this means hardcoding decisions such as: 

    • If the communication between services is local or distributed—allowing for concurrency or distribution
    • If services are to be considered stationary or mobile—pinned to a specific physical address or free to be relocated
    • How the services can respond to failure—self-healing bulkheads that can be migrated to other nodes if needed or tied at the hip with the failed node

    Locking in decisions like this upfront will make the system harder to run efficiently, evolve, adapt and maintain over time. These should not be design or development decisions, not deployment decisions, but runtime decisions, not affecting the code. 

    It’s hard to predict the future. This includes knowing how an application will be used over time, how changes in usage and load patterns will evolve, and how future features or changes in business requirements will impact the initial design, assumptions, and runtime/operational characteristics. 

    Not having to take these decisions or worry about how they will be maintained efficiently but only focusing on API, data model, and business logic reduces time to market and overall risk substantially. 

    Here’s my vision for data…

    Data always exists wherever and whenever needed, but only for the time it is needed.

    • Having the latest and correct data always available to you right when you need it and wherever you happen to be located—in the central cloud or at the far edge—sounds like a developer’s dream.
    • On the other hand, it’s been said that “laziness is a virtue,” which is very much true of data management in a distributed system. Replicating data to locations where it will never be needed is a loss (unless needed for resilience/failover). The same is true for holding on to data longer than needed (holding resources hostage and forcing needless consistency mechanisms). 
    • Balancing this is very hard and should ideally be done by the platform adaptively at runtime at a global system level, rather than by the developer.

    Data is always co-located with processing and end-user—ensuring ultra-low latency, high throughput and resilience. 

    • If not, as in traditional three-tier stateless architecture, data is often somewhere other than where you need it to be and therefore has to be fetched before being used and pushed out to storage after modification. This increases latency, reduces throughput and puts the service at the mercy of the availability of the storage service.

    Data and compute move adaptively together with the end-user. 

    • Many use cases at the edge serve users on the move (e.g., cell phones, cars). To serve these users as efficiently as possible, their data and compute need to move geographically with them. 

    Data is injected into the services on an as-needed basis—automatically, timely, efficiently and intelligently. 

    • Data storage management is often very intrusive in application design and business logic: How to map domain objects to DB tables (OR-mapping), transaction management, storage API calls for fetching and updating the state, etc. 
    • Externalizing all of this to the platform and instead having the data injected into the service when new data is available (just as we are used to with events in a pub/sub system) makes the code easier to design, write, understand and maintain. 
    • Additionally, if the service is doing all data management itself, then it’s a black box to the platform. The platform has no idea what access patterns have been used, on what data, when data can be safely cached, replicated, sharded, prefetched, shared, etc. On the contrary, if the platform is doing all the data management, then it can look broadly across all services and safely optimize data management for the overall system holistically. 

    I believe RedMonk analyst Steve O’Grady’s concept of vertical integration fits well into this narrative. It all leads to what I feel is a distillation of a cloud-to-edge programming model (a continuum, as described previously). This model is about abstracting away everything that is not core business value, leaving the three things that can never be delegated: Data model, API and business logic. 

    As Timothy Keller said, “Freedom is not so much the absence of restrictions as finding the right ones, the liberating restrictions.”

    By using a serverless developer experience (DX), I believe the answer to extending real-time data and computing to the edge can be realized in a fully managed developer PaaS model. That model abstracts away all infrastructure into a single declarative programming model and effectively unifies cloud-native and edge-native development. This is “vertical integration” and the cloud-to-edge data plane vision.

    Conclusion

    Today, cloud computing and edge computing are typically treated as separate domains. However, rapidly evolving demands for intelligent low-latency processing of edge-generated data are creating requirements for a new approach combining cloud and edge into a single continuum. With cloud-native applications, architects and developers have already embraced the concepts required to build services that run in an essentially infinitely scalable (but logically centralized) cloud infrastructure. Extending this thinking to a fully decentralized infrastructure, including the edge, is a natural next step in enterprise application architecture. Programming models that enable a data-centric, location-transparent approach combined with intelligent runtimes that automatically enable data and processing to be co-located where and when needed will allow developers to take full advantage of such a wholly distributed edge-to-cloud environment.

  • Fire at Data Center Causes Chaos | 20% Costlier Cloud

    Fire at Data Center Causes Chaos | 20% Costlier Cloud

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: A South Korean conflagration leads to a ridiculously long outage, and the price of public cloud is skyrocketing. (more…)

  • More Choices, More Problems: The Double-Edged Sword of Multi-Cloud

    More Choices, More Problems: The Double-Edged Sword of Multi-Cloud

    Multi-cloud environments can be a double-edged sword. On the one hand, there are clear benefits to using whatever cloud or tool is best for your particular needs, regardless of vendor – in theory. In practice, however, the more choices you have, the more complex and expensive your environment becomes. In fact, Andreessen Horowitz postulates that multi-cloud architectures are oftentimes costing enterprises more than if they had stayed with on-premises systems.

    Enterprises need a multi-cloud environment to compete in such a rapidly expanding digital economy. For the majority of companies, completely repatriating to on-prem isn’t an option–the train has already left that station for most. But what do you do when the costs of staying competitive become more and more prohibitive, ironically making you less competitive?

    Hybrid Clouds Became Multi-Cloud

    When hybrid cloud–a mix of public cloud services and on-prem systems–became table stakes for enterprises, companies only needed one public cloud service provider. Most put all of their eggs in the AWS basket, splitting their workloads between AWS public cloud services and on-premises systems.

    This setup provided more agility and flexibility to enterprises and lowered costs by reducing dependence on expensive, cumbersome on-prem hardware. A lot of capex was replaced by opex; with cloud services, you only pay for what you use as you use it without the physical infrastructure and maintenance costs.

    Inevitably, the cost and efficiency benefits of the cloud drove companies to migrate more and larger workloads from their on-premises systems, increasing cloud costs over time. And the more workloads you had with a single vendor, the more beholden to that vendor you became. If AWS raised their prices, you had no alternative but to pay more.

    Soon, hybrid clouds grew into multi-clouds, with other public cloud providers such as Azure and GPC in the mix. Sometimes this was by choice–why be locked into one vendor and suite of tools when you could choose from multiple vendors that might offer better pricing or have some products that are better suited for your needs?

    More often, though, it was involuntary–developers spinning up their own clouds and resources for their own purposes without consulting IT, creating shadow IT. Or companies acquiring other organizations whose cloud choices varied. Either way, the enterprise is using multiple clouds whether they planned to or not.

    Regardless of how it happened, once more clouds were introduced, complexity multiplied.

    The Multi-Cloud Hydra

    Too many organizations underestimate the complexity they’re introducing with each additional cloud. Operating systems, networking, cost monitoring and tracking, workload methodologies and data aggregation are all different for each vendor. How many people in your organization know what all these differences are and how to navigate between them? How do you effectively manage, govern and monitor usage, costs and security and compliance issues when each public cloud does it differently? You have to manually collect data from each cloud and aggregate it in spreadsheets for analysis. How accurate can that be, how long does it take and at what cost in terms of people and time?

    Furthermore, how will you be able to accurately pinpoint waste and inefficiency? If you’re chasing down engineers to turn off resources or having to choose between one manual cost-efficiency action versus another, the waste will add up and your budget will be inaccurate.

    As if that’s not chaotic and complicated enough, development teams spread out across the enterprise adopt different tools and use them for their own purposes, without any alignment or coordination. The same tool is purchased multiple times. Best practices between teams aren’t shared. Everything needs to be custom-coded, creating layers of “spaghetti code” that blur visibility and are ripe for misconfigurations, which results in security vulnerabilities. And let’s not forget shadow IT, which IT departments don’t even know about, let alone monitor.

    You started your journey with a unified cloud strategy, but now you’re struggling with an ever-growing number of different clouds and strategies for different groups. Each group prefers different tools, clouds, methods and processes, and this has left you stuck with siloed teams, unending tool sprawl, infinite lines of custom code, worsening security risks and no clear visibility. And the meter keeps spinning, costing you millions.

    So, what do you do now?

    Taming the Chaos

    To survive and thrive in the new cloud order, enterprises can’t just write off exploding cloud costs as “the cost of innovation,” or otherwise justify their cloud chaos as par for the course. Too many are doing that now, and it won’t end well, as we’re likely headed into recession and growing uncertainty and turbulence in markets.

    First and foremost, taming cloud chaos and getting multi-cloud costs under control requires visibility and interoperability. You must be able to view, monitor, manage and analyze all clouds from one place; manually collecting that data with spreadsheets won’t do anymore.

    Development teams can no longer be siloed off from each other. There should be a single repository where all teams can access and utilize all tools, scripts, and previously coded integrations. When everything is viewable and available in a single place, no one has to buy the same tool twice or reinvent the wheel when using it. Once a tool has been integrated, any other team that wants to use that tool can simply re-use the integration, configuration, and policies that have already been created and vetted. If multiple groups are doing the same thing, an approved automation process can be created and shared.

    True cost optimization also requires organizational awareness and shared responsibility. If people don’t know they’re wasting resources, how will they be able to stop? Enterprises need a system that detects waste and cost overruns and notifies stakeholders accordingly.

    For example, a development environment may be up and running even though it’s no longer being used. An automatic alert could be sent to the appropriate team leader, reminding them to shut it down. A developer provisioning cloud resources might not choose the most cost-effective option, but the alert system would flag their activity and notify them of a cheaper alternative. Cloud resources that are left on overnight or on weekends would also be detected and shut down. Commitments would be conducted automatically every day and no longer require individuals to remember to do them manually.

    There’s just no going back to the traditional whack-a-mole style of cloud management and cost control. Enterprises that understand this and create a holistic framework for cloud management capabilities based on simplicity, visibility, unity and awareness will be in a much better position to navigate the choppy economic waters to come.

  • Oracle Enables Partners to Reuse Cloud Platform

    Oracle Enables Partners to Reuse Cloud Platform

    At its CloudWorld event, Oracle today announced it will enable IT teams to deploy the same platform it uses to independently deliver cloud services anywhere they see fit.

    Leo Leung, vice president of products and strategy for Oracle, said an Oracle Alloy offering will enable organizations to provide a full set of cloud services they can extend and brand as their own. All of the more than 100 infrastructure and platform services that the company makes available on Oracle Cloud can now be deployed anywhere, he said.

    In addition, Oracle unfurled a MySQL HeatWave service through which IT teams can access instances of the open source MySQL database running on the Amazon Web Services (AWS) cloud. A similar offering for the Microsoft Azure cloud is also planned.

    As part of an ongoing effort to gain share against rival cloud service providers, Oracle has been making a wide range of services available at a lower cost. Oracle Alloy now extends those efforts by making it possible for a wide range of organizations, including traditional enterprise IT organizations and internet service providers, to benefit from the company’s research and development efforts.

    Organizations that ally with Oracle can set their own pricing, rate cards, account types and discount schedules and define the support structure and service levels. A preconfigured instance of Oracle Fusion Financials to enable Oracle Alloy partners to manage customer invoicing and billing is also provided.

    It’s not clear to what degree these organizations might want to compete with cloud service providers such as Amazon Web Services (AWS), Microsoft and Google, but Oracle Alloy does provide an alternative approach to cloud computing that enables organizations to retain more control over the IT services they provide to others. The challenge, of course, is that acquiring the infrastructure is only one part of the equation. Organizations will also need to hire and retain IT specialists needed to manage cloud platforms on an ongoing basis.

    As the volume of applications being deployed in cloud computing environments steadily increases, Oracle clearly views Oracle Alloy as an opportunity to make up for lost ground in a market segment that it initially all but ignored when cloud computing first emerged more than a decade ago. Now, Oracle provides cloud services in 40 commercial and government regions across 22 countries. It has added 10 public cloud regions over the past year and has plans to add six additional commercial regions.

    Oracle is betting that, in some cases, partners will opt to deploy some cloud services themselves while relying on Oracle for others depending on the level of demand for specific classes of services. In effect, Oracle is enabling a set of federated cloud services to emerge that are no longer specifically tied to a single provider. It remains to be seen how receptive organizations will be to that approach, but it’s certain that the number of organizations that could afford to deliver cloud services could substantially increase. In theory, at least, increased competition should also lead to lower cloud costs for the organizations that consume those services.

  • Google Looks to Secure Software Supply Chains

    Google Looks to Secure Software Supply Chains

    At the Google Cloud Next ’22 conference, Google today launched a managed Software Delivery Shield (SDS) service to enable DevOps team to store, manage and secure the build artifacts in Artifact Registry. At its core, SDS is based on a trust-based policy engine to establish, maintain and verify a chain of trust across the software supply chain.

    In addition, Google has updated its container analysis tool to include vulnerability scanning for Maven and Go containers along with preview support for non-containerized Maven packages.

    The managed Software Delivery Shield service spans a range of Google runtimes environments, including Google Kubernetes Engine (GKE), Cloud Code, Cloud Build, Cloud Deploy, Artifact Registry and Binary Authorization. Cloud Build also now officially supports Supply chain Levels for Software Artifacts (SLSA) Level 3 best practices by default in addition to generating authenticated and non-falsifiable build provenance for both containerized applications and non-containerized Maven and Python packages.

    GKE, in preview now, provides detailed assessments, assigns severity ratings and surfaces the security posture of the clusters and workloads, including insights into operating system vulnerabilities, workload configurations and other actionable insights. Log data can now also be captured while security event information can be routed to, for example, a security information and event management (SIEM) platform.

    The Google Cloud Run serverless platform can also, in preview, display software supply chain security insights such as SLSA build-level compliance, build provenance and vulnerabilities found in running services.

    At the same time, Google is also making available in preview Cloud Workstations, which provide fully managed secure development environments on Google Cloud that can be accessed via a browser. Built-in security capabilities include virtual private cloud (VPC) controls, no local storage of source code, private ingress/egress, forced image updates and identity access management (IAM) policies.

    Finally, the Cloud Code plug-in for integrated development environments (IDEs) now includes a preview of Source Protect to give developers real-time security feedback in the form of vulnerability dependencies and license reporting as they write code.

    Collectively, Google claimed it now provides more than 250 curated packages across Java and Python with verified provenance. It also automatically generates a software bill of materials (SBOM) to create an inventory of all components and dependencies.

    Historically, cloud service providers have been advocating a shared responsibility approach to cloud security that required organizations to not only secure their applications but also the way cloud infrastructure is provisioned. The challenge is developers generally provision cloud infrastructure themselves even though they generally have limited cybersecurity expertise. Too many developers assume the underlying cloud infrastructure is more secure than it actually is.

    Now, cloud service providers are extending the security services they provide at a time when organizations are making security a bigger factor in determining where to build and deploy applications.

    Sunil Putti, vice president and general manager for Google Cloud Platform, said Google is attempting to make cybersecurity invisible to developers in the sense that guardrails will automatically be embedded within the platform.

    The issue is that cloud computing environments are becoming more complex as new classes of cloud-native applications are deployed alongside legacy monolithic applications. Complexity, as always, is the enemy of cybersecurity.

  • GitLab Allies With Google to Improve Developer Productivity

    GitLab Allies With Google to Improve Developer Productivity

    GitLab Inc., in collaboration with Google, today launched an open source Cloud Seed tool that makes it simpler for DevOps teams to consume Google Cloud Platform (GCP) resources.

    The Cloud Seed tool, announced at the virtual Google Cloud Next ’22 conference, is integrated within the GitLab web UI to make it simpler for developers to consume Google cloud resources—such as Cloud Run for building and deploying containerized applications—and the managed Cloud SQL database service.

    Nima Badiey, global vice president of alliances for GitLab, said the goal is to reduce friction that would otherwise be created by requiring developers to write code to consume these services using a set of lower-level application programming interfaces (APIs).

    That self-service approach not only improves productivity but provides the added benefit of reducing the odds those services might be misconfigured in a way that creates a cybersecurity vulnerability, he added.

    As it seeks to gain ground on Amazon Web Services (AWS) and Microsoft, Google has a vested interest in working with providers of DevOps platforms to make it simpler for developers to consume cloud resources. The challenge is that developers often make mistakes when they programmatically invoke cloud services. Those resulting misconfigurations are all too often not discovered and remediated until after there has been some type of cybersecurity incident.

    In the wake of a series of high-profile breaches of software supply chains, there is a lot more focus on security. The challenge, of course, is finding a way to ensure application development platforms are as secure as possible without slowing down the rate at which software is developed and deployed. Achieving that goal requires the right mix of policies, training and systems, said Badiey.

    Most organizations are trying to strike a balance between the need for greater security and their need to attract and retain developer talent. In theory, the rise of DevSecOps best practices is pushing more responsibility for security further left toward developers. However, most developers have little to no cybersecurity expertise, so it’s clear more guardrails need to be built into DevOps tools and platforms to prevent cybersecurity mistakes from being made.

    It’s not clear how much improved developer productivity and greater security will drive organizations toward one cloud platform versus another, but in an age where many more organizations now routinely employ two or more cloud platforms, it could make a significant difference. Developers don’t especially enjoy remediating applications after they are deployed in a production environment because they have generally already moved on to other projects. IT operations and cybersecurity professionals are also likely to nudge developers toward platforms that create the least amount of operational overhead for them.

    Regardless, one thing that is certain is compliance requirements are about to become stricter for all concerned as scrutiny of software supply chains intensifies in the months ahead. The issue now is how to proactively address those requirements before they become a much larger issue.

  • What’s Next for Cloud Computing? Distributed Cloud

    What’s Next for Cloud Computing? Distributed Cloud

    The public cloud has greatly advanced IT by allowing teams to interact with their data and write new applications in a cloud-native way. The cloud simplifies the application development process, provides services on demand and allows you to pay as you go. There has been phenomenal growth in public cloud use and all estimates show that it is likely to keep growing in the near future. 

    Nevertheless, most IT computing still takes place outside of the public cloud, simply because there has been no effective way to consume cloud-native services outside of data centers (or “regions”) operated by the hyperscale cloud providers. This location constraint negatively affects cloud computing in three main ways: Performance (latency, throughput), data sovereignty (residency, regulations) and commercial considerations (legacy architecture, pricing). 

    As a result, to realize the cloud’s fullest potential, many enterprises are turning to a recent innovation in cloud computing: Distributed clouds that are untethered to specific locations or regions.  

    How does this work? Through APIs, the distributed cloud connects to any IT stack in any location and provides cloud functionality as if running on a hyperscale cloud. However, instead of running in a dedicated location, it runs on existing infrastructure on top of any IaaS, virtualized environment or bare-metal machines. It is agnostic to the stack’s underlying physics and doesn’t require any installation or capex. It runs workloads in any environment: Commercial data center, on-premises facility, edge microcenter or even in a multi-facility hybrid environment. 

    How the Cloud is Transforming Enterprise and SMBs

    Modern application development lives and breathes cloud computing. It’s been the enabler for much of the recent progress with modern applications—such as those dedicated to IoT, smart cities and personal health, for example—and will continue to be the infrastructure on which enterprises and small businesses develop new innovations. But as more and more businesses employ a cloud-first approach using cloud-native architectures and technologies, “IT budget” has become synonymous with “cloud budget.” And this is often a very expensive proposition.

    Therefore, the next step for many businesses is to manage cloud computing costs while supporting legacy and cloud-native applications as well as cloud migration. Their computing strategy may be simultaneously on-premises, bare metal and hybrid across multiple continents. And so they need a cloud with architectural latitude to match their needs as well as their budget. 

    This flexibility is provided by the customizable distributed cloud. By facilitating interoperability with existing infrastructure, it enables enterprises to deploy and infinitely scale applications anywhere they need. The more openness they have in terms of where they run applications, the more freedom they have to optimize their budget. 

    Who is Driving Cloud Computing Innovation?

    Amazon, Microsoft and Google have gone from being the innovators in cloud computing to being the incumbents. Innovation in the cloud is coming from startups as well as legacy IT companies. Here are a few examples:

    • Kyndryl has emerged as one of the system integrators of choice when the Fortune 500 look to innovate and modernize their IT and application infrastructures. Kyndryl has been engaged by large companies to solve many of the challenges that cloud computing has created. One of the innovations they have championed is the distributed cloud.
    • NetApp has spent over $2 billion on more than a dozen acquisitions to build their cloud portfolio. Their focus has been on creating a portfolio that gives enterprises the ability to bridge their various compute and storage infrastructures to the cloud. As opposed to assuming that their customers will have greenfield implementations on cloud infrastructure, NetApp has built a portfolio that allows them to meet their clients where they currently are in terms of architecture and to shift from there into more cloud-native capabilities. 
    • Zenlayer has built cloud infrastructure in diverse geographies, giving them global reach that even the hyperscalers can’t rival. Zenlayer claims to provide cloud infrastructure that is so globally distributed that they are within 25 milliseconds of latency from 85% of the world’s internet population. This focus on physical infrastructure locations that enable global performance is an important innovation for many modern applications. 

    Emerging Cloud Computing Innovations

    The distributed cloud, which integrates programmatically into any existing local infrastructure, is an innovation that drives businesses forward by providing them with a cloud that can be customized for specific locality requirements. Without requiring any installation, its cloud-native building blocks leverage existing servers to run application workloads in any environment—private, public, on-premises and hybrid. 

    As a result, application owners are able to build an optimized cloud computing strategy, taking advantage of existing and available infrastructure in the location—or multiple locations—of their choosing.  

  • EvolveWare Further Automates App Modernization Tasks

    EvolveWare Further Automates App Modernization Tasks

    EvolveWare today announced it has added an Agile Business Rules Extraction capability to its Intellisys application modernization platform.

    EvolveWare CEO Miten Marfatia said the Agile Business Rules Extraction capability eliminates the need to freeze code development while applications are either being shifted to the cloud or refactored. Instead, the Intellisys platform will now keep track of updates to code and apply them once the application has been modernized, he said.

    Code updates can now be transferred automatically into the extracted business rules repository without affecting the rules that are not impacted by the updates. For rules impacted by the updates, a report is generated that highlights the changes. IT teams can now also update business policies and modernize applications concurrently via the repository that also keeps track of documentation such as diagrams, logic, database details and critical dependencies, said Marfatia.

    In addition to presenting logic in multiple formats, including pseudo-code, flowcharts, decision tables and business analyst language, it enables consolidation and optimization actions to be reverted to their original state if required.

    In general, IT teams have been struggling with application modernization efforts that require them to either lift and shift a monolithic application running in an on-premises IT environment into the cloud or refactor it into a set of microservices that run natively in the cloud. Eventually, most organizations will refactor monolithic applications, so the debate becomes to what degree to undertake those efforts before lifting and shifting an application into the cloud. Most monolithic applications were not designed to run in the cloud, so when the app is shifted it’s not uncommon for any number of performance issues to be encountered.

    EvolveWare claims that its Intellisys platform reduces the cost of application modernization by as much as 60% by eliminating much of the manual effort that would otherwise be required. Modernization efforts, in general, are hindered by manual processes that should be automated, said Marfatia.

    The issue that most DevOps teams encounter when modernizing an application is that it is not a task they regularly perform. As such, many of the processes required have not been automated with the same level of zeal they’ve applied to more routine manual tasks. The Intellisys platform is designed to enable IT teams to automate the most common tasks associated with migrating an application to another platform.

    The biggest driver of those migrations these days has been digital business transformation efforts that have accelerated since the start of the COVID-19 pandemic. Organizations of all sizes are moving applications to the cloud to ensure greater availability and resiliency to limit the amount of disruption that might be encountered should the pandemic worsen, or in case some other unexpected event makes accessing IT services difficult.

    The challenge, of course, is moving applications—and the database they depend on—from one platform to another is not easy. It can take some organizations months, sometimes even years, to make the transition. Given the backlog of applications that many organizations are looking to migrate to another platform, it’s clear there is a need for much higher levels of automation to accelerate a transition that, on its present trajectory, might take years to complete.

  • Cosmonic Previews Deployment Platform for Distributed Wasm Apps

    Cosmonic Previews Deployment Platform for Distributed Wasm Apps

    Cosmonic has made available a preview of a platform for deploying applications built using the portable WebAssembly (Wasm) binary format that enables applications to be deployed on any platform.

    Cosmonic CEO Liam Randall said the company is providing early access to the Cosmonic Platform Developer Preview platform to enable developers to experiment with a new type of software artifact that will be used to build a new class of cloud-native applications.

    The Cosmonic Platform Developer Preview platform is based on wasmCloud, an open source application runtime that hosts components written as Wasm modules that can then be loosely connected to build applications. Originally developed under the auspices of the World Wide Web Consortium for building browser applications, Wasm is a portable binary instruction format for building software that describes a memory-safe, sandboxed execution environment.

    That approach replaces the current predominant method for building software that relies on the aggregation of software components that tend to lack distinct boundaries. It’s that lack of distinct boundaries that enables malware to flow so easily from one software module to another. The wasmCloud runtime, originally developed by Cosmonic, provides a platform for deploying distributed Wasm applications and is now being advanced under the auspices of the Cloud Native Computing Foundation (CNCF).

    Prior to Wasm, Randall noted, every format for building applications led to the creation of ‘walled gardens’ that resulted in developers being locked into a platform. Wasm is the first software artifact that enables applications to run on an platform, including Linux and Windows, without any modification required, said Randall.

    It may be some time before Wasm becomes the preferred artifact for building applications, but it’s clear the walls that have separated one IT platform from another are about to crumble. Once applications become much more portable, the longstanding goal of writing an application once and then deploying it anywhere may finally be achieved. Just as importantly, those applications will run in a memory-safe sandbox that is more secure than what can be enabled in legacy IT platforms. In fact, as more organizations review the security of their software supply chains, they may decide to accelerate their embrace of Wasm to build more secure applications.

    Naturally, the transition to Wasm will have major implications for DevOps teams, as it represents an opportunity to streamline deployment processes across multiple platforms. In effect, the total cost of application development and deployment would decline as processes spanning multiple platforms become more automated using platforms such as wasmCloud. Ultimately, much of the infrastructure complexity that developers need to navigate today would be eliminated, noted Randall.

    It’s not clear just yet to what degree Wasm will drive a transition to another era of computing, but the potential to change almost every aspect of IT is on the horizon. Ultimately, the issue will be decided by how quickly developers are willing to embrace yet another software artifact for building and deploying applications. What is clear is that the number of platforms that will make it possible to experiment with Wasm are starting to multiply.