devopsy.kinsta.cloud

Tag: platform-as-a-service

Solving the Speed Paradox With Open Source PaaS
The number of DevOps tools keeps growing, as does the number of cloud resources and options to manage those resources. On EC2 alone, AWS offers nearly 400 instance types across storage, networking and operating systems. Complicating this further is that users can choose from machines located in 24 regions and 77 availability zones.

This proliferation is driving a ‘speed paradox’ wherein the faster you grow the more fragmented and complex your ecosystem becomes which, in turn, slows everything down. Most DevOps teams struggle to keep up with the demand for more environments from developers.

The Speed Paradox

The Rise of the Internal Developer Platform (IDP)

One intriguing solution to the speed paradox is the internal developer platform (IDP). As its name suggests, an IDP provides a single place where developers can find all the resources needed to run their environments. An IDP allows developers to speed development processes by offering improvements in:
- Efficiency – Simplifying access to development and testing infrastructure through a self-service experience;
- Consistency – Providing a consistent way to consume infrastructure resources across teams; and
- Visibility – Providing a single place to see all the pipelines, workflows and states associated with each environment.
Gartner sums it nicely: “Product teams often struggle due to disparate tools and disjointed workflows as they accelerate digital transformation. Software engineering leaders leading platform teams must establish internal, self-service developer portals to enable consistency and scale cloud, agile and DevOps initiatives.”

Lessons From the ‘PaaS-t’

The idea of a developer platform isn’t new. Previous-generation PaaS—Google App Engine, Heroku Cloud Foundry, for instance—provided a simple interface to write applications by abstracting cloud resources. But early PaaS failed, perhaps mostly due to the long tail of developer needs. Back in 2013, I observed:

“Every Access project will eventually fail because, while 80% of what the user wants is fast and easy to create and the next 10% is possible with difficulty, ultimately the last 10% is impossible because you can’t get far enough underneath the built-in abstractions and users always want 100% of what they want.”

You can sum up the failures of early PaaS in three points:
- Too opinionated: It is hard (impossible?) to control the way the platforms run their infrastructure resources. You’re dependent on the platform vendor for customization.
- Limited to simple web applications and language choices: Modern SaaS applications are complex and include backend services that don’t fit that architecture.
- Maturity: Early PaaS attempted to abstract cloud when it was a young, moving target.
What’s Changed?

With early PaaS, we traded simplicity for flexibility. Finding the right balance between the two is the heart of the challenge. Kubernetes and Docker, as well as IaC tools like Terraform, Cloud Formation and Azure ARM are a great substrate: They provide a consistent framework to manage applications across a wide range of infrastructure resources among clouds. Maturity and adoption of these tools reduces barriers to build a developer platform. This opens the opportunity to create a custom platform for each organization, allowing teams to control how their platform fits into their organization’s environments. It also offers balance between simplicity and flexibility, because each organization can choose where to draw the line—and even redraw that line without being dependent on an external vendor.

The next-generation platform

Enter Backstage

Backstage is an open source IDP project led by Spotify. Its three main parts are:
- Service Definition—Based on the Kubernetes template format, it provides a service descriptor that fits into a range of services: monitoring, CI/CD and Git repositories
- Backstage service catalog—Basically a web application with a database backend providing a single point of access to manage resources
- Integrated tooling via plugins —A marketplace of integrated resources
Here’s how an IDP based on Backstage can look:

An example of an internal development platform based on backstage

We can use Backstage to organize all development services and resources such as our squad KPI, the development pipeline, API and Git repositories, all in one place.

Turning Backstage Into a Full-Blown PaaS

One of the missing pieces in Backstage is infrastructure provisioning. Adding it turns Backstage into something closer to a full-blown PaaS. Cloudify provides a remote execution engine that integrates with a variety of infrastructure resources and allows users to organize them into a self-service development or production environment. The integration of Cloudify into Backstage includes synchronizing the development environments into the Backstage service catalog and allowing self-provisioning of those services through the Backstage portal or through GitOps.

Integrating Cloudify as a remote execution engine to Backstage

You can watch a demo or get more information on the integration from the Cloudify Backstage Git repo.

The End of ‘Growth At Any Cost’

Last year, Sarah Wang and Marti Cassado analyzed the impact of cloud spending on hypergrowth companies. As tech companies trade away efficiency in pursuit of velocity, they face a non-sustainable growth model where cloud costs surpass 50% of total revenue. Wang and Cassado’s analysis illustrates how this condition directly impacts a company’s profitability—and valuation.

In today’s market upheaval, it’s even easier to see how a “growth at any cost” policy is unsustainable. Today, DevOps teams have to find ways to support growth while controlling costs. This forces organizations to better control how development teams use cloud infrastructure.

IDPs can become a major tool in this effort. Unsurprisingly they’re becoming the next hot DevOps trend. Backstage provides a great framework and ecosystem to shorten the time a team needs to build its own internal platform and Cloudify provides the open, remote execution engine with a single place to organize infrastructure resources into a self-service environment. The integration turns Backstage into a full-blown PaaS.

The current Cloudify-Backstage integration is only an MVP release. Next, we’ll deepen the integration, providing more monitoring within the Backstage portal. Here, you can find more information on our open source contribution to Backstage and offer feedback.

An Open Source Solution to the Speed Paradox

The “speed paradox”—where the faster you grow the more fragmented and complex your ecosystem becomes, which in turn slows everything down—need not grind our DevOps agility goals into the ground. By using open source Cloudify integrated into the Backstage project, DevOps teams can avoid becoming the new bottleneck in software development agility goals.
June 3, 2022
GitLab Gets an Overhaul

GitLab launched its next major iteration, GitLab 15, starting with its first release version, 15.0, which the company said pulls together new DevOps and data science capabilities into the platform. With GitLab 15, GitLab says it provides (or soon will provide) continuous security and compliance, enterprise Agile planning, visibility and observability, workflow automation and increased support for data science workloads.

In an interview with devopsy.kinsta.cloud, Hillary Benson, director of product management, detailed how GitLab 15 provides several security benefits, including the ability to automatically create an exportable software bill of materials (SBOM) and signed attestation for build artifacts, centralized security policy management including a two-step exception approval process, as well as providing compliance managers the ability to see project history changes and better enforce policy. “Supply chain security, especially, has become a major area of focus for us, both because it’s become a high priority in the industry and because GitLab is uniquely positioned to support customers well in this area,” Benson said.

GitLab 15 also provides improved static application security testing (SAST) with stronger and more flexible rules and finding management, Benson said. Finally, users can pool together GitLab project data to create custom automations.

According to Benson, GitLab 15 will also introduce more capabilities that interlink data across every stage of the DevOps life cycle from initial planning, implementation, deployment and monitoring. “Some of the things that will happen in this area are additional options for the types of work items that can be managed,” said Benson. That includes supporting a more diverse range of workflows and frameworks—including enterprise Agile frameworks. The platform will continue to support issues, epics and requirements and soon enable tasks, features and objectives.

GitLab 15 provides new capabilities the company hopes will increase visibility and enable an end-to-end view of value delivery and application health, the company said. The unified collaborative context will help remove DevOps silos within organizations and decrease incident rates as well as provide comprehensive insights into issues that hinder performance in addition to real-time triaging of incidents. These new capabilities can help shorten lead times from code to production, reduce error frequency and severity, help development teams deploy more frequently and reduce mean-time-to-recover (MTTR) after an incident.

Upcoming features include improved product analytics and experimentation, such as increasing the practicality of surfaced data by enabling testing and validating new ideas and measuring the adoption of DevOps best practices across teams and projects, Benson said. Expanded support for all DevOps research and assessment (DORA) metrics including improvements to value stream analytics for projects and groups is also addressed. “This is about making it easier to understand what value your product is bringing,” said Benson. “We’re introducing product analytics and experimentation to increase the practicality of the data that you’re using and the data you’re collecting to actually move your product forward,” says Benson.

Finally, GitLab 15 will increase support for data science teams and their workloads. “This is about streamlining the development and deployment of machine learning models to train and test those and then get them into production. We’ll also be working on providing monitoring for those workloads so that it can be understood if those models are being used, how they’re being used and where there may be performance issues,” said Benson.

May 23, 2022
Cloud Foundry Foundation Updates CLI to Extend DevOps Processes

The Cloud Foundry Foundation (CFF) today released an update to its command-line interface (CLI) that will enable DevOps teams to build more granular and complex workflows spanning multiple processes across the open source platform-as-a-service (PaaS) environment.

Announced at the Cloud Foundry North American Summit, version 7 of the Cloud Foundry CLI employs updates to the application programming interfaces (APIs) exposed via the Cloud Foundry PaaS to invoke package, droplet, build and process control resources while adding resources such as sidecars, manifests and deployments.

The updates to the CLI and associated APIs will make it possible to enable rolling application deployments, run multiple processes within the same container and add metadata to objects.

Chip Childers, executive director of the CFF, said most of the organizations that have adopted the Cloud Foundry PaaS are already fairly advanced when it comes to implementing best DevOps practices. The latest version of the CLI will make it possible to tighten DevOps feedback loops within the PaaS environment.

In general, CFF is positioning the Cloud Foundry PaaS environment as a common framework for building and deploying applications on traditional virtual machines and Kubernetes clusters. The CFF has launched an incubation project, dubbed KubeCF, that enables a virtual instance of the Cloud Foundry runtime to be deployed on Kubernetes. At the same time, the CFF has made available Project Eirini, another incubation project that enables the Cloud Foundry scheduler to be replaced by Kubernetes, and Project Quarks, which allows the CF Application Runtime to be packaged using containers.

The CFF has also launched Cloud Foundry for Kubernetes (cf-for-k8s), a more ambitious effort to replace the underpinnings of the PaaS environment with a Kubernetes foundation. That initiative should result in Cloud Foundry requiring much less IT infrastructure to be deployed. The CFF has also committed to embracing other cloud-native technologies such as the Istio service mesh.

As part of that effort, the Bosh framework that the CFF created to automate the deployment of its PaaS will also eventually be replaced by a framework optimized for Kubernetes environments.

Childers said it’s now clear Kubernetes will mature to the level required to support an enterprise-class application development environment. The opportunity now is for IT vendors such as VMware, SUSE and others to deliver an application development environment that makes developers more efficient than any other on cloud-native infrastructure, said Childers.

For example, VMware today is making available a public beta of the VMware Tanzu application service for Kubernetes based on the cf-for-k8s project.

Contributors to the CFF project are clearly trying to make up for lost time. Rival PaaS environments such as Red Hat OpenShift have long been integrated with Kubernetes. The CFF community, however, is betting more enterprise IT organizations will embrace Kubernetes once they discover various distributions of a PaaS environment they already rely on is available on that platform.

Whatever the path chosen, the one thing that is clear is the Cloud Foundry PaaS is about to become a lot more accessible to organizations that, no matter how great the developer experience, previously balked at its overall size.

June 24, 2020
Castles in the Cloud: How to Take Your Business Kingdom Off-Prem with Confidence
Cloud transformation requires migrating all or part of an organization’s virtual assets off-premises, typically to a public cloud. This enables greater efficiency and cost savings, among other benefits, but it brings heightened risk as well. At the same time, many organizations moving to the cloud don’t fully understand the implications in terms of security. Consequently, successful cloud migration requires a shift in mindset.

A Medieval Metaphor for Cloud Infrastructure

Think of your organization as a kingdom surrounded and protected by a castle. Traditionally, this castle would be outfitted with defensive layers designed to protect the residents, the royal family and the possessions within. Protection of the castle is straightforward. A moat surrounds the castle with drop bridges in and out at strategic points (firewalls).

In addition, guards are stationed at each entry point, conducting a thorough inspection of the people, carts and the content that they carry both in and out of the castle (IDS/IPS). The guards also check credentials at the gates and within the castle to ensure patrons are cleared for access and use of rooms and resources (IAM). The perimeter and interior walls are continuously checked for weaknesses that could introduce potential blind spots that are unguarded (vulnerability management).

The castle has a variety of rooms, each with its own function, content and worth. Each door has a lock (AV). Within each room and the correlative hallways exist guards who check credentials, monitor the people who enter and the contents they carry, etc. (behavioral detection and endpoints). In addition, multiple other measures are in place that bolster prevention, detection and response capabilities (DLP, deception, etc.). Information from all of these sources is noted in a central location by a scribe. Guards analyze the information, looking for additional indicators of potential threats to the kingdom (SIEM) and respond accordingly.

Comprehensively, protection of the kingdom requires an overall model and policies that accounts for new threats and tactics from rival kingdoms and thieves. Architecture of security measures are continuously updated and adaptable. In the event of an incident, the guards have designed and exercised a plan to respond.

Understanding the Three Different Models of Cloud

Clearly, this is a basic metaphor for the on-prem approach. Moving to the cloud introduces a new level of complexity to protection spread across three different models: Infrastructure as a service (IaaS), Platform as a service (PaaS) or Software as a service (SaaS).

In the context of our castle analogy, let’s assume the castle has reached productive capacity. Neighboring rivals are creating competitive pressures, offering residents (who pay taxes) the possibility of a better life if they relocate. To keep residents happy, productivity requires expansion beyond castle walls. As production expands, neighboring kingdoms offer different models to achieve productivity. However, each model presents different levels of shared responsibility in protection (referred to as the Shared Responsibility Model).
- IaaS: In this model, the on-premises kingdom (kingdom A) decides to expand all operations to a neighboring castle (kingdom B). The castle itself and the moats are all controlled and provided by kingdom B. However, the infrastructure, moats, hallways, rooms, access lists, monitoring of activity and protection and usage of its contents are the responsibility of kingdom A.
- SaaS: Kingdom A decides to have blacksmithing conducted in a neighboring castle (kingdom B). The castle itself, the moats, infrastructure, hallways and blacksmithing room are all protected by kingdom B for a charge. Kingdom B’s responsibility is to control access to the room, but maintaining who’s on the access list to the room and the protection of its contents and usage are the responsibility of kingdom A.
- PaaS: Kingdom A decides to house and build military operations in a neighboring castle (kingdom B). Kingdom B is responsible for the basic controls, but the configuration and monitoring remain the responsibility of Kingdom A.
With this transformation, Kingdom A faces a more complex security landscape. Innovation and efficiency are critical to meeting the growing and changing demands of their kingdom, but not without additional risks. New operating models bring new risks and potential vulnerabilities to their system(s). Methodologies and processes used to secure their own kingdom do not necessarily work or apply to protecting their new partner kingdoms. Additionally, people–and experience–that understand these new complexities are harder to come by while the thieves and rival kingdoms discover vulnerabilities and weaknesses and begin to exploit and steal valuables that put the entire kingdom and its residents at risk.

Protecting Your Castle in the Cloud Takes a Deep Understanding

Moving to the cloud is almost inevitable at this point, and it carries so much potential to accelerate business outcomes. It takes a different mindset to secure it than what we are used to as an industry–the landscape has been changed from a security perspective. By fully studying and understanding the differences, organizations can continue rapid and secure adoption of the cloud, while reaping the benefits that it promises to bring.

— Sean Blenkhorn
February 28, 2020
DevOps Deeper Dive: SUSE Sets DevOps Course

There was a time when SUSE was considered to be the second-biggest force driving the adoption of Linux in the enterprise, after Red Hat. Then came an odyssey to rival any epic written by Homer. A few short years after moving its corporate headquarters from Germany to Oakland, California, the company was sold to Novell, which was then later acquired by Attachmate. Three years later, Attachmate was acquired by Micro Focus. Three years after that, SUSE (as an arm of Micro Focus) acquired distributions of OpenStack and the Cloud Foundry platform-as-a-service (PaaS) from Hewlett-Packard Enterprise (HPE).

That brings us to 2018, when SUSE was spun out of Micro Focus to become an independent company once again, headquartered in Germany once again. A year later Melissa Di Donato, formerly chief operating officer (COO) of SAP, was named CEO of SUSE. A few months after that, SUSE announced it would withdraw its distribution of OpenStack from the market to focus its efforts on emerging cloud-native opportunities stemming from the rise of Kubernetes.

For SUSE, those opportunities arise from a distribution of Kubernetes deployed on its Linux operating system, which also serves as the foundation for its container-as-a-service (CaaS) environment, along with a version of Cloud Foundry deployed on top of Kubernetes.

Brent Schroeder, global CTO for SUSE, said his company’s strategy is being driven by an acute need for increased flexibility. IT environments are inherently becoming hybrid as more workloads move to the public cloud, and many organizations will want to leverage a common substrate based on Kubernetes for building and deploying applications. In some instances, Kubernetes will be deployed on top of virtual machines, while in other use cases Kubernetes will be deployed on bare-metal servers. IT organizations will then decide to deploy a CaaS or PaaS depending on their requirements, said Schroeder, noting that regardless of the path chosen, IT modernization initiatives will create a significant opportunity for SUSE.

“Virtual machines, bare-metal and the cloud will be a huge catalyst,” said Schroeder.

DevOps, of course, is playing a major role in driving those transitions, which Schroeder said has become a major focus for SUSE as organizations think through how to not just build and deploy applications faster, but also secure and govern those processes. That latest version of SUSE CaaS Platform 4, for example, added support for Cilium open source project for securing network connectivity between containerized application services.

Of course, SUSE is not the only IT vendor making this journey. Red Hat was the first to deploy a PaaS environment on top of Kubernetes and since then has been on a mission to obliterate the distinction between a CaaS and a PaaS environment. As an arm of IBM, Red Hat has also significantly expanded its market research as IBM builds out a hybrid cloud computing strategy based on the Red Hat OpenShift platform.

Of course, Red Hat’s acquisition by IBM might create new opportunities for SUSE. After all, more than a few of the IT organizations that opted to embrace Red Hat OpenShift had plenty of opportunities to consider alternatives from IBM. Now that the acquisition has been finalized, some of them may be reconsidering their options.

It’s too early to say when SUSE might arrive at its ultimate destination. When venture capitalists buy a company such as SUSE the goal is to either take the company public or recoup the investment by selling it to another entity. Whatever the outcome, it’s clear SUSE intends to leave its mark in the brave new world of containerized applications.

— Mike Vizard

November 11, 2019
Survey: IT Striking Balance Between Innovation, Reliability

When it comes to managing IT, most DevOps teams are locked in an eternal struggle to balance innovation with reliability. There’s always a keen interest in being able to take advantage of the latest and greatest IT platform. However, new IT platforms don’t achieve the level of maturity required to build and deploy mission-critical applications overnight. Enterprise IT organizations often build an application on one platform and deploy it on another platform that is perceived to be more reliable.

But a global survey of 505 IT and other executives published by the Cloud Foundry Foundation (CFF) suggests that, at a time when adoption of microservices based on containers and serverless computing frameworks is rising, the need to strike a balance between innovation and reliability has never been more acute.

Conducted by ClearPath Strategies on behalf of the CFF, the survey finds serverless usage and container usage are now at 14% and 37% respectively. At the same time, adoption of platform-as-a-service (PaaS) environments such as Cloud Foundry has increased to 47% from 41% in the last six months.

The study also suggests the rate at which organizations are adopting serverless computing and containers is starting to plateau. However, organizations that have adopted serverless computing frameworks and containers are making greater use of these capabilities as they continue to mature, according to the survey results.

CFF CTO Chip Childers said it’s not uncommon for organizations now to deploy a PaaS and Kubernetes platforms alongside each other. In some cases, applications built using containers on a Cloud Foundry PaaS will be deployed on a Kubernetes run-time at the network edge. In other cases, applications built using development frameworks running on Kubernetes will be deployed on a Cloud Foundry PaaS that is perceived to be more reliable.

Of course, the percentage of organizations that are employing a PaaS environment is not nearly as high as those using a less opinionated framework for building applications. However, whatever the path chosen, Childers said multiple types of abstractions that simplify IT complexity will live alongside one another for many years to come. At the same time, the underlying technologies that enable those abstractions increasingly will converge. For example, the Cloud Foundry PaaS was built before Kubernetes existed. Now the CFF is moving toward replacing much of the Cloud Foundry substrate with Kubernetes.

According to the survey results, 65% of respondents place the most value on a platform that delivers a consistent experience. However, 59% also said a platform that integrates innovations is of the greatest value to their ability to develop software applications. In addition, almost two-thirds (63%) said a technology’s ability to integrate with their environment is the “touchstone” that makes technology better.

As is often the case, what constitutes a touchstone is in the eye of the beholder. However, DevOps teams are not likely to sacrifice reliability no matter how cool that next big thing in IT may or may not be.

— Mike Vizard

October 22, 2019
Render Taps Manifold to Expand Cloud Services for Developers

The rate at which DevOps teams that rely on cloud services from Render will be able to discover new tools is about to increase significantly, thanks to Render’s new alliance with Manifold, a provider of a marketplace-as-a-service platform.

Render already offers logging, monitoring and other DevOps tools, and will use the Manifold technology to create its own marketplace. Render CEO Anurag Goel said the partnership will provide his company with a platform that enables instant access without having to navigate as many configuration steps because Manifold has automated those processes.

Goel said Render has been growing at a rate of 50% per month by focusing on the needs of developers, a strategy that has resulted in more than 100 million http requests a week on the Render platform. That approach has allowed the company to differentiate its cloud platform from much larger rivals such as Amazon Web Services, Microsoft Azure and Google Cloud Platform, which are not as focused on the developer experience, he said.

Manifold CEO Jevon MacDonald said Manifold has focused its efforts on building a marketplace that allows smaller cloud service providers to offer tools and applications with a user experience that rivals any of the marketplaces provided by the big three cloud service providers but without having to build and maintain that marketplace themselves. Manifold also works with each provider of tools and applications on the marketplace to automate the configuration process, he said.

Over time, marketplaces have proven to be critical for cloud service providers because they provide the foundation on which developer ecosystems are created. The easier a cloud service provider makes it for DevOps teams to discover new tools and applications, the larger that ecosystem tends to become.

Obviously, AWS, Microsoft and Google have massive DevOps ecosystems in comparison to Render. However, with the rise of cloud-native platforms such as Kubernetes, it will become much easier for DevOps teams to build applications on one cloud platform and deploy them on another. To attract developers of cloud-native applications, Render has built a containerized platform as an alternative to legacy platform-as-a-service (PaaS) environment.

Render is betting that cross-platform strategy for building applications becomes more commonplace, more developers will opt to build applications on cloud platforms specifically focused on providing a superior developer experience. Current Render customers include smaller startups such as 99designs, Gatsby and Indie Hackers by Stripe.

As developers start to shift toward cloud-native technologies, it remains to be seen how many DevOps teams will be willing to consider alternative cloud platforms. The major cloud service providers have built business models around providing as little support as possible. While it may not be possible for cloud service providers to support each DevOps team with an expensive support contract, there does appear to be plenty of room for cloud service providers to create a richer developer experience that goes beyond a basic one-size-fits-all approach.

— Mike Vizard

September 30, 2019
Survey Sees Cloud Foundry Momentum Gains

At a time when many organizations are wondering to what degree they should rely on legacy application development and deployment platform versus emerging container-based platforms, the Cloud Foundry Foundation (CFF) today released the results of a survey that shows reliance on the organization’s namesake open source platform-as-a-service (PaaS) environment continues to grow.

Announced at the European Cloud Foundry Summit, the annual survey of 306 IT professionals finds 45% of respondents describe their use of the PaaS as “broad,” compared to 30% a year ago. The same survey finds nearly 20% started using Cloud Foundry in just the last 12 months and 39% of developers are deploying applications now in less than one day. More than three-quarters (77%) report application development cycles of fewer than three weeks.

Nearly half of survey respondents report they have at least 100 developers using the PaaS, a significant jump from just one-third last year, and the share of companies with more than 50 applications on Cloud Foundry grew to 43% in 2019.
The future of the PaaS has been called into question ever since the rise of Docker containers and Kubernetes. The CFF has been slow to adopt Kubernetes as a more efficient foundation for deploying a PaaS environment. Most recently, the CFF has provided organizations that adopt the PaaS the option of replacing the Diego container orchestration engine developed by the CFF with Kubernetes. At the same time, the CFF is working toward replacing much of the foundation layer for Cloud Foundry with Kubernetes to provide a more efficient means of standing up a Cloud Foundry environment.

The CFF has also made it possible to deploy applications built on Cloud Foundry on a Kubernetes runtime. CFF CTO Chip Childers says that no one should be surprised when the rise of Kubernetes leads to more adoption of Cloud Foundry. Most of the application development environment available for Kubernetes today are not as robust as the Cloud Foundry PaaS, with the notable exception of the Red Hat OpenShift PaaS. Following the acquisition of Red Hat, IBM is now promoting Red Hat OpenShift as the cornerstone of a hybrid cloud strategy that has Kubernetes at its core. Meanwhile, last month Pivotal Software, provider of a curated instance of a Cloud Foundry PaaS, told financial analysts it expected to see a $40 million to $50 million decline in revenue in fiscal 2020. Shortly after, VMware moved to acquire Pivotal, which, like VMware, is a unit of Dell Technologies.

An update to a previous report published today by source{d} shows there are now 879 repositories in the Cloud Foundry GitHub organization, with the total number of commits reaching approximately 50,000 per month. The report finds the highest levels of activity are centered around the Stratos UI project, Istio integrations and the core Cloud Foundry Application Runtime Cloud Controller.

The CFF and Kubernetes, under the auspices the Cloud Native Computing Foundation (CNCF), fall under two separate arms of The Linux Foundation. It’s unclear if the Linux Foundation might one day merge these two arms or continue to keep them separate as a means of navigating conflicting vendor strategies. Whatever the outcome, Cloud Foundry is likely to remain a vibrant part of the open source community for many years to come.

— Mike Vizard

September 11, 2019
Dell Technologies Drives Automation Deeper into Platforms

Dell Technologies this week launched a series of initiatives intended to provide IT organizations with multiple deployment options for Dell EMC appliances and servers, including forthcoming managed service offering through which Dell will manage private cloud platforms based on VMware software on behalf of customers.

Announced at the Dell Technologies World 2019 conference, Dell EMC also unveiled a new appliance series and revealed an alliance with Microsoft under which its VMware arm will make available cloud software on the Microsoft Azure cloud, in addition to existing support for Amazon Web Services (AWS), IBM Cloud and servers deployed on-premises.

Jon Siegal, vice president for product marketing for converged platforms and solutions at Dell EMC, said Dell EMC plans to make it easier for IT organizations to consume IT infrastructure in an on-premises IT environment as a service or continue to use their capital budgets to acquire servers and appliances.

To advance that latter approach, Dell EMC is launching VxFlex, a set of appliances that include an operating system that enable compute, storage and networking separately. In contrast, the existing VxRail series of appliances are optimized for VMware and assume compute, storage and networking will be scaled in tandem, said Siegal. Dell EMC is also now unifying a set of hyperconverged appliances and converged infrastructure servers under a common VxFlex brand, and Siegal said in the future those offerings will be extended to add support for Kubernetes alongside platforms from vendors other than VMware.

At the same time, Dell EMC is previewing a VxRail Analytical Consulting Engine (ACE) that will be embedded in VxRail HCI system software that Dell EMC provides in its appliances optimized for VMware. That analytics engine employs machine learning algorithms to maximize application performance, while also providing self-optimization recommendations and capacity forecasts.

The Dell Technologies Data Center-as-a-Service offering, meanwhile, is scheduled to be generally available in the second half. It marks the first time Dell has launched a managed service under its own brand. VMware, however, has been providing managed services for the past year. The Dell Technologies Data Center-as-a-Service offering extends that concept to include Dell EMC VxRail appliances.

Automation is clearly at the heart of the evolving Dell Technologies strategy. The challenge organizations that have embraced DevOps will face is aligning their processes with the automation frameworks Dell Technologies is embedding in both VMware and the underlying infrastructure on which VMware gets deployed. To address that issue, Dell Technologies over time will bundle frameworks such as the open source distribution of the Pivotal platform-as-a-service (PaaS) environment from Pivotal Software, an arm of Dell Technologies, on its platforms, Siegal said.

These moves signal Dell Technologies is trying to fulfill a promise to make it as easy to manage IT infrastructure deployed in an on-premises IT environment as it is to manage on a public cloud. There’s obviously still a gap. But as Dell Technologies starts to make IT infrastructure available as a service, it may one day become challenging for DevOps teams to tell where any one cloud happens to be running at any given moment.

— Mike Vizard

April 30, 2019
Fintech: A Profitable and Growing Developer Career Path

What do you think when you hear the word “fintech”? It’s been around for almost five decades, yet it has only just been officially recognized as part of the English language. In the Merriam Webster dictionary, the word is defined as: “Products and companies that employ newly developed digital and online technologies in the banking and financial services industries.”

A number of factors in recent years have paved the way for the boost in profile for fintech, bringing about phenomenal growth in the sector. In some parts of the world, governments and regulatory bodies have fueled this growth by issuing regulations that open up the banking sector to increased competition, creating a great many opportunities for finance and technology professionals alike. And from the other side, not only are banks being at most compelled, and at least pressured, into opening up to competition, many are now actively seeking to collaborate with more agile third parties—namely fintechs and developers —to innovate the services demanded by their customers.

So, what exactly are the opportunities available for developers in this newly defined sector?

From the Classroom to the Boardroom and Beyond

I am confident that there has never been a better time than the present for developers to get involved in the financial services industry. It’s a bold statement, but one that bears out when the remarkable amount of support being directed at fintech is considered.

Today, the industry is receiving unprecedented political backing as multiple jurisdictions vie for fintech hub status. From the United States to Hong Kong, from Germany to the UK, governments are offering financial support via tax incentives and grants in a bid to woo fintechs and developers to their financial centers. And it’s no wonder, given how lucrative a business sector it has proved to be. In the first half of 2018, VC-backed fintech companies reportedly raised more than $25 billion in funds. CB Insights’ data shows there are currently some 29 fintech unicorns (venture capital-backed, private businesses worth more than $1 billion) worldwide, with an aggregate value of $84.4 billion—and this is expected to keep on rising.

Even educational support is being offered to future-proof against skills shortages, with academia and financial firms collaborating to create fintech-related graduate training schemes and degree courses.

Open Banking

Around the world, particularly in Europe and parts of Asia, governments and industry bodies are lighting the way for a new approach to collaboration with fintechs and developers. In Europe, the second payments Services Directive (PSD2) and the UK’s Open Banking initiative are opening up the financial services market to third parties eager to enter the space. These initiatives, and others like them, compel banks to share their precious data with third parties at the request of their customers—meaning they can no longer take their hitherto market hegemony for granted.

Here in the United States, the Consumer Financial Protection Bureau (CFPB), the body that regulates the offering and provision of consumer financial products and services, has released a set of data sharing principles that provide an advisory framework for financial institutions. Though the CFPB’s guidelines are non-binding, they do show that there is growing pressure from regulators for the financial sector to be more transparent with customer data.

Collaboration is Key

When it comes to collaboration between fintechs and banks, one might expect there to be a certain amount of resistance from both sides. Fintechs are traditionally disruptors, while financial institutions don’t take kindly to being disrupted. A pPlatform-as-a-service (PaaS) approach can help enable collaboration that is beneficial for both sides.

The ability to collaborate through a common platform, hosted in the cloud, offers the potential for fintechs to significantly reduce application development time, often from months to weeks. Users can bring innovation to market at pace using a low-code, cloud environment and sell applications to the banks without needing to build a global sales team or worry about a scalable infrastructure. Pre-integrated developer tools, a sandbox environment and an API catalogue also speeds application creation and levels the innovation landscape. With platforms, the fintechs with the deepest pockets no longer dominate the market simply because they have the resources to snap up opportunities. In the platform sandbox, smaller firms, startups and independent developers can bring their own offerings to the table.

As the model for bank innovation changes, a platform approach also makes it easier for financial institutions to transform their businesses, extend product capabilities and access innovation. Banks can leverage their own development capabilities to create and deploy applications on top of their core systems and can collaborate with fintechs to build and access new capabilities they need quickly through open APIs.

A key part of the PaaS approach also gives developers the ability to make apps available to banks globally through a digital shop front, much like Apple’s iOS App Store. So, not only are developers and fintechs able to distribute and monetize their apps, banks can readily test and deploy them.

Get Onboard

Financial institutions are starting to recognize that an open platform approach is the fastest way to onboard fintechs to enhance their current business offerings. As this understanding deepens, so too will the demand for skilled professionals and new applications. Banks in the not-too-distant future will not only concern themselves with the services they want to deliver, much consideration will be given to the fintechs most able to provide them in a timely manner.

It’s not just in retail banking that the opportunities lie, but across all areas of financial services—from investment management to corporate banking, payments, trade finance and capital markets. The coalescence of these two considerations is leading to a change in the industry zeitgeist, meaning the scope for innovation across all areas has widened significantly. The great earning potential for those with the ability to convert good ideas into innovative apps and services has never been more apparent.

So, developers, as banks wait with open arms (and APIs), now is the time to enter the burgeoning world of fintech.

— Mitesh Soni

December 12, 2018