Category: Cloud Management

A Guide to Cloud Migration Trends and Strategies

For several years, we have witnessed widescale cloud adoption as a software infrastructure growth and maintenance strategy. Spending on cloud application services (SaaS) continues to grow as monolithic applications are replaced by microservices-based apps and monoliths become relics of the past. In 2021 alone, companies spent $410.9 billion on public cloud services, and Gartner expects this number to rise by 20.4% in 2022 to reach $494.7 billion. But as this movement continues to evolve, engineering leaders preparing their cloud migration strategy must be up to speed on the latest key trends.

Is Migrating to the Cloud Cost-Effective?

For companies migrating to the cloud now, the process is no longer a simple transition from on-premises to remotely hosted servers. Cloud service providers now offer a wide variety of options, and companies run the risk of overspending in the cloud marketplace.

A lack of clarity of their business and product needs or submission to shiny object syndrome can drive companies to spend on non-essential services, especially during migration. It is easy to fall into this trap; companies only realize it after they have committed and try to undo the damage by reversing the process.

Although many public cloud providers offer pay-as-you-go pricing, companies often purchase more services than they use. When companies are unclear about their objectives, such expenditure is more extravagant than the utility. This awareness of cloud spending has encouraged companies to take stock of their needs and expenses, and when they do not add up, to consider partly shifting back to on-premises.

But Isn’t On-Premises a Thing of the Past?

Not yet, but gone are the days of mindlessly unloading entire infrastructures into the cloud. Increasingly, companies are aware of the costs of pulling their data from the cloud.

For many, security and control concerns motivate them to keep data on-premises. The public cloud has its benefits, but private storage has its place, too, especially for some components of your software. All in all, on-premises is here to stay, as companies continue to acknowledge and appreciate its value despite their reliance on public cloud environments.

Why Do Companies Choose Cloud Migration in 2022?

Cloud technologies can potentially deliver faster and better-performing experiences to end users, while innovations are giving rise to new services that cloud vendors can capitalize on. Various use cases are surfacing as companies understand the cloud better and see its potential. They are pushing the boundaries on how they can use the cloud, and cloud service providers are keeping track of the changing nature of the demand.

For example, cloud-based gaming platforms like Amazon Luna are seeing significant growth. The cloud is also of great value to artificial intelligence and machine learning efforts, and these are often intertwined.

The Great Resignation phenomenon also drives some companies towards the cloud. Although some knowledge is needed when moving to the cloud, cloud services offer automation and require less employee supervision in the long term.

The COVID-19 pandemic has also been a catalyst for accelerating cloud adoption, making resiliency a priority. Companies can stay afloat in an emergency if their workloads are moved to the cloud. It comes at a cost, sure, but allows companies to outsource time-consuming responsibilities and focus resources elsewhere. While this was most significant in 2020 and 2021, this logic remains relevant.

Cloud computing is also helping companies improve performance, efficiency and scalability. In addition to AI, the cloud will be instrumental in the development of more powerful augmented and virtual reality apps.

Approaches Defining Cloud Migration Today

The possibility of these approaches or facilities also motivates companies to migrate to the cloud:

Containerization: The process of compiling and storing a service, along with its dependencies, in a container. Due to their small size, multiple containerized applications can run on a server, allowing for easier and cheaper shipping of the service. According to CNCF’s 2021 Annual Survey, containerization is now a mainstream practice, and Kubernetes, for instance, is a heavyweight in this domain, with 96% of companies employing or evaluating it.

Security: In Q1 of 2022 alone, 90% of data breaches had their origins in cyberattacks. Mindful of this alarming trend, companies are factoring security concerns into their cloud adoption strategies. We are also witnessing a shift in businesses’ approach to security via DevSecOps: Incorporating security as a continuous practice from the beginning of the software development life cycle instead of relegating it to the back-burner until the last moment. Additionally, frameworks like secure access service edge (SASE) and customized cloud disaster recovery strategies are becoming essential elements of cloud adoption.

Sustainability: Sustainability is becoming a key component in most business models. Companies are eager to adopt practices and models that reduce their carbon footprint. This impetus is also emerging from business partners and investors who are beginning to employ sustainability as a critical factor when deciding which companies to work with. When a cloud migration is planned carefully, chances are that you will retire certain services in your infrastructure and make decisions about what to migrate and what to retain. By optimizing your migration strategy, you are likely to only run and pay for the services you need, ensuring that your energy expenditure is under control.

Edge computing: Edge computing, a $176 billion market in 2022, emphasizes the importance of building data centers locally; i.e., closer to where they are needed for storage and computational purposes. It solves any bandwidth and latency issues. Improved security is another added benefit of this practice. Edge computing has a bright future as it attempts to compensate for some of the pitfalls of using centralized servers in the cloud.

Cloud-native applications: Cloud-native applications are easier to work with on the cloud, as they are designed and built on the cloud itself, not rearchitected to ensure compatibility with cloud services. When compatibility is not a concern, they can leverage various benefits offered by cloud services. As a result, scalability, flexibility and resilience are built into these applications. With cloud adoption, companies are increasingly in favor of cloud-native applications. This subsequently informs their migration strategy as they decide which services to retire, rearchitect or build anew once the actual migration is complete.

How Does the Hybrid Cloud Fit In?

Hybrid computing is on the rise as it leverages the public and the private cloud to deliver maximum benefit to companies with little to no compromise. The public cloud offers scalability, flexibility and speed, while the private cloud provides cost-effectiveness, security and compliance with regulations. While sensitive data can rest on the private cloud, frequently accessed data can be stored in public servers like AWS and Google Cloud. Investing in a hybrid cloud strategy from the point of migration itself can go a long way in giving companies access to the best of both worlds.

Similar to a hybrid cloud environment, a multi-cloud strategy where companies distribute workloads across multiple clouds put some control into the company’s hands and ensures additional flexibility. By working across cloud services, companies can pick and choose which services are most compatible with their application’s components. These can include services offered by different cloud providers.

Cloud Providers Seeing Growth, and What They are Doing Differently

Serverless cloud environments: Cloud vendors like Amazon, Microsoft and IBM are pushing serverless cloud services. Although these continue to rely on servers (despite the name), companies don’t rent servers or pay fixed charges. Instead, the storage and bandwidth infrastructure scales with the software as and when it requires it. Companies do not need to concern themselves with technicalities and can focus on innovation and improving their existing applications. An added advantage is the provision of safe testing environments that encourage developers to tinker with cloud services and develop solutions for potential failures or outages. Serverless cloud solutions are also beneficial for smaller companies that need not invest large amounts of capital to ensure growth.

Partnerships: To meet the soaring demand for cloud services, partnerships among cloud providers are also on the rise. By partnering with other service providers, companies can offer more services by leveraging the resources and reputations of one another while strengthening their competitive edge in the cloud market.

Industry optimization: Cloud adoption is not limited to software companies. Businesses across industries like healthcare, finance and retail are migrating their infrastructures to the cloud. This variety in demand has encouraged providers to customize their services to meet the specific requirements of each industry. Often, these include regulatory compliance needs in these sectors.

The cloud is only getting bigger and better. You can develop a well-curated transition strategy with the knowledge of current cloud migration trends. Additionally, identifying your requirements at an early stage will go a long way in leveraging the cloud to your advantage.

August 1, 2022

API Gateway Vs. Service Mesh: What’s the Difference?

In the average microservices architecture, app programs trade the stability and rigidity a call stack offers for the network’s flexibility. Consequently, latency, security and traceability issues that were previously absent become a service call concern.

Service mesh is the resulting solution to eliminate these issues and allow developers to focus on more important business solutions. The caveat is the functionality overlap that exists between a service mesh and an API gateway. But while the two are similar, there are also key differences between both options. Here’s what you need to know.

Defining a Service Mesh

A service mesh is a comprehensive architectural pattern set designed to deal with enterprise concerns like instability, debugging and security. These concerns arise when a team moves from a call stack to network calls.

For instance, a function call via a call stack recognizes the constant availability of the requested function. On the other end of the equation, a network call doesn’t offer this functionality.

A service mesh is the preferred option because it assists the system’s client endpoint in managing network instability. The primary method for solving this network instability is frontrunning retries transparent from the client app’s viewpoint.

The service mesh also assists the server’s endpoint by rerouting incoming requests to the server node that’s best able to deal with the incoming request. The choice of server node is a function of previously determined policies for routing incoming traffic.

The ideal service mesh is installed with two layers: The control plane and the data plane. The latter is a proxy for any connection’s server and client endpoints.

The data plane also enforces policies from the former while running operation metrics to a monitoring tool. Conversely, the control plane layer manages all attending service policies alongside the data plane’s operation.

Image Source

Key Features of a Service Mesh

The average service mesh has a number of primary features.

But there are a few things that bear mentioning. Say your app development team is working on a small business phone system. This particular service implementation doesn’t need every feature listed below. It depends on your team’s specific needs and traffic setup.

Traffic Routing

This feature enables the service mesh to route requests based on preset configuration or a predetermined policy. The system may prioritize traffic from specific client applications. Alternatively, a service mesh can re-route traffic to different service versions for:

A/B testing
Canary release
Service versioning

Observability

Service mesh implementations feature proxies that record service calls for individual clients and services. This feature takes the manual burden of the call-logging process away from the developers.

Plus, teams can leverage downstream analysis and monitoring tools to report on system availability and overall performance. These monitoring tools also provide a framework for basic tracing across all call chains.

The observability capabilities of a service mesh extend beyond the above. For example, some coding work can allow developers to improve call chain monitoring to allow for accurate tracing for enterprise business transactions.

Common service mesh observability features include:

Latency, error rate and throughput alerts
On-demand service dashboards and graphs depicting the connection between individual services
Tracing the journey a business transaction or request makes through the service mesh

Image Source

Security Policies

An application with multiple independent services has a huge attack surface. Essentially, each independent service is a vulnerable entry point that requires protection. A service mesh has proxies on both the server and client endpoints to secure any communication between both terminals.

A service mesh also improves security by eliminating the dependence on developers to manually program security into every service. Instead, the server proxies will handle authorization, authentication and encryption for each independent service. The resultant effect is a zero-trust security framework.

Identity

A service mesh manages who can access individual services. It also maintains a real-time log of stakeholders accessing each service and when they did so. The system validates identity through JSON Web Tokens (JWTs) while allowing authorization depending on the requesting service and the stakeholder.

Encryption

Compliance, security and data protection are key considerations. Well, communication between all services in a service mesh is fully encrypted. The control plane is responsible for certificate management functionality including certificate rotation and generation.

Furthermore, a service mesh uses mutual TLS where both server and client endpoints whitelist the certificates that can operate on the other side of any connection. A service mesh provides robust mutual TLS authentication, allowing for seamless system authentication and encryption.

Resilience

This feature defines the ability of a service mesh to insulate developers in scenarios where the principal service function goes offline. In some instances, the proxy may follow an alternative service path or switch to a backup framework.

For illustration, streaming giant Netflix has a personalized user recommendation feature that suggests titles to its users. If this service goes offline, a service mesh system can ensure a switch to a default recommendation feature with zero personalization. Only when this backup fails will the system return an error code.

A service mesh assures developers that when a service fails, the proxy has done all it can to manage communication errors. In some cases, the mesh can ensure optimal performance by switching to a different service with the lowest latency.

Examples of configurable resilience patterns for a service mesh include

Circuit breaker patterns
Rate limiting
Retry policies

Another illustration of a service mesh’s resilience is the ability to build chaos engineering capabilities. The service mesh can inject itself into the endpoints within the network, providing the observability required to monitor a chaos test.

Image Source

What an API Gateway Entails

Whether the team is working on contract management software for small business or an expense calculator app, the choice of API can determine the results of your team’s app development efforts. But more than the choice of API, proper management is another crucial talking point. The best results come with a system that identifies incoming calls, directing them to the appropriate resource.

API gateway is the future of DevOps and is the solution to that need. It’s the technology framework for routing API client calls to the ideal application. It also processes the call, forwarding resulting responses to the client’s network.

At the technical level, an API gateway isn’t a must-have. Find a developer with a digital business card, hire them, and they can always program an embedded code responsible for call request routing. The only caveat to this alternative is the manpower and resources necessary to program and insert codes for individual call requests. As such, it’s always better to have an API gateway to handle this task.

An API gateway is a more innovative solution because extensive coding always holds the possibility of risks and errors. Furthermore, these errors can complicate app development stages like maintenance, bug fixing and application testing.

The API gateway ensures all API requests reach their intended destination with zero diversion. Plus, it also offers the following added functionalities:

API request monitoring
Shifting API requests between individual nodes
Request balancing for multiple instance situations

The Major Differences Between API Gateway and Service Mesh

An important digital workplace definition that differentiates both frameworks is the placement location. The API gateway is necessarily present on public-facing systems. Other key areas where an API gateway and service mesh differ include:

Observability

Observing the performance of the average API gateway is a more concrete task. The framework can provide actionable data insights like how long the API takes to respond to requests, problematic features, and their impact on network traffic.

With the service mesh, the ability to spot performance issues is a given. However, the system can’t ascertain any effects of performance lags on end-user response and experience. Therefore, while troubleshooting is easy, gauging the extent of the problem’s impact is more complicated.

The Communications They Handle

Both frameworks manage different communication nodes—one handles internal discussions and the other external ones. The API gateway is the component responsible for routing external communications. For example, the API gateway handles chatbot connections, purchase orders and visits to specific pages.

Conversely, the service mesh is responsible for internal communications in the system. For illustration, a discussion between multiple microservices under the same app environment will fall under the service mesh’s purview.

In other words, the API gateway manages client-server discussions. Meanwhile, service-service communications are for the service mesh.

Management

Both frameworks may have some areas of overlap, but the amount of management each one requires isn’t one of them. API gateways are simpler to manage and develop. As such, they’re easier for your app development team to manage.

The deployment for an API gateway happens just once, regardless of the service app. Plus, post-deployment centralization and monitoring are easy tasks.

In contrast, a service mesh is more complicated and tedious to manage. Your app development team must deploy the service mesh function for individual app systems.

Compatible Tools

Most API gateway tools and software resources are highly expensive. Plus, they’re compatible with every popular app architecture.

The other end of the equation offers more accessibility. There are countless service mesh tools and resources for varied functionality. Plus, the majority of these support tools come at zero cost because they are open source. For example, there’s Envoy and Istio, both of which are free and open source.

However, you shouldn’t expect to enjoy cross-platform compatibility across these service mesh tools. For example, Istio is only compatible with Google. On the other hand, AWS App Mesh—another service mesh tool—is compatible with AWS Cloud.

Image Source

Difference	API Gateway	Service Mesh
Existing Functionalities	Useful for API requests between the client and server Compatible with external API requests and internal calls.	Handles internal communications Best for improving the portability of service-to-service calls
Digital Transformation Functionality	Longer app delivery cycles Zero security risks	Useful for effective microservices management Speeds up the network’s delivery cycle Security risks due to open loopholes when the program runs alone
Operations	Reroutes API calls present outside of the given application environment	Works within the application architecture
Maturity Level	API gateway is mature technology. It has been a core developer tool for several years now	Service mesh is still a relatively new technology and requires more research and development
Security Processing	Automated security protocol	Manual security systems
Usage Complexity	Application complexity remains constant with endpoints remaining unchanged	Business scalability can be complex as each update comes with new endpoints

Can Service Mesh and an API Gateway Be Used Together?

The unlikeliest of brands often form marketing partnerships. In the same way, there are instances where using both a service mesh and an API gateway is a logical and feasible idea.

While differences exist between an API gateway and a service mesh, it’s not an “either/or” situation.

Cloud contact center teams looking to streamline communications at both the internal and external levels are already leveraging both technologies. And you can also leverage both systems to achieve the following:

Improved Innovation

Effective API use, especially during external interactions, requires internal resource optimization, which is better when teams deploy a service mesh alongside an API gateway.

Image Source

Accelerated Digital Transformation

Leveraging both resources improves enterprise digital transformation rates. Plus, any application with both technologies will enjoy a unified API gateway for internal service mesh management. If there are any linked applications, the unified API makes them simpler to handle.

Increased Security Scalability

Scalable container security is achievable when you deploy a service mesh and API gateway together. The service mech will boost the system’s interservice connectivity while the API gateway acts as a central point for all client-server requests.

The API gateway also provides the much-needed technical support for increased proxy security. It also fosters quick threat detection and resolution at the proxy level.

API Gateway and Service Mesh are Different

Both the API gateway and service mesh are designed to simplify communication while also reducing any coding responsibility on the app development team. While both systems can ensure network calls through an enterprise contact center reach the target destination, they’re structurally different.

Above, we’ve highlighted the key differences between both frameworks. But despite these differences, both systems are compatible and can work together for improved app development. We recommend leveraging a service mesh and an API gateway together for better security, innovation and app scalability.

August 1, 2022

How 5G Will Change the Public Cloud as We Know It

When it comes to realizing the promise of 5G, we’re still a few years away. Under the hood, though, the rollout of 5G infrastructure and the new applications 5G will enable—from AR and VR to new drone capabilities and beyond—will drive dramatic changes in infrastructure demands, starting with the public cloud.

In the 5G era, many of the applications that will become possible and take advantage of this network infrastructure will require a tremendous amount of data to be moved and processed—whether for a connected car, video surveillance with real-time analytics, or AR/VR—so much so that the data needs can’t really be solved at the responsiveness that these applications will demand from the centralized public cloud as we know it. As 5G creates a new ecosystem, a lot of these applications are going to be built in new ways and rely on the attributes of edge clouds: Edge computing delivered as a cloud-like service. Underpinning it will be cloud-native architectures and other highly automatable and flexible infrastructure to help make it a reality. Let’s take a look at some of the key elements.

What is an ‘Edge Cloud’?

SaaS companies building applications in the public cloud today are used to self-service, elastic infrastructure. You don’t have to think about hardware, you pay per use, there are APIs to take advantage of, and most importantly everything is highly automatable and flexible. More than likely, you need only think in terms of a handful of centralized locations as you build—a site on the west coast, one on the east coast, one or two in Europe or Asia.

In the 5G future, that will likely no longer be the case. Many new, revenue-generating services will depend on low-latency, high-bandwidth capabilities that enable applications and data processing to get closer to the user or device. Everything from industrial applications, IoT, to immersive infotainment (virtual and augmented reality) to telemedicine and more will be able to take advantage of the 5G network and edge-compute processing to deliver new capabilities and experiences.

Services like these depend not only on connectivity but also on the ability to gather data, process it, and more importantly, move and act on it at very high speeds.

In this new world, you still want the same things from your infrastructure—it needs to be elastic and capable of scaling up and scaling down. And reliability, automation, and agility (the ability to iterate and deploy quickly) become even more important. And it needs to be available and running in many, many more places in order to be close to the customers and devices you are serving. You’re not thinking about three locations across the globe or two or three across the U.S. Instead, you may be thinking about a couple of dozen in one metro area alone. A whole new kind of compute environment has to be built around that, as well as a cloud infrastructure environment.

The Multi-Mode Present, and What’s Next

5G environments will require very flexible infrastructure that can be highly automated, repurposable, and usable in very generic ways. If you are building metro, point-of-presence data centers all over the country, it is not cost-effective to use highly specific infrastructure for each application in each site; it is too limiting in flexibility and too onerous to manage at scale.

One aspect of the infrastructure challenge is that service providers still rely in part on monolithic, traditional applications that tend to run in physical or virtualized environments to make them deployable, controllable and able to be automated. But newer applications are being designed with a different technology stack based on containers.
With applications that live in both areas, flexibility across VMs and containers is a must. As a result, rollouts of 5G will employ a multimode infrastructure, combining both virtual machines and containers in order to support both legacy and modern applications. The goal: Easy automation everywhere.

Virtualized and container environments will need to live and operate in concert with one another. They both require automation, but because each has its own needs it’s important to choose a technology stack and approach that will incorporate and work with both.

While virtual machines and virtualized network functions (VNFs) are more prevalent today, that won’t remain true for long. As carriers move to microservice architectures that drive continuous improvement and speed time to value, adoption of CNFs is growing.

The Road Ahead

Since it is still early days for 5G use cases, architecture flexibility will allow carriers to pivot toward any killer apps that emerge. Data-centric infrastructure that can deliver both performance, agility and flexibility is essential.

As we look out at the possibilities for 5G, it’s helpful to think back to the early 1990s. With AOL dial-up and a 2400 baud modem, you could email, surf the web (though it was painfully slow) and play a few games. The advent of broadband ushered in entirely new applications and use cases like e-commerce and media streaming and drove the infrastructure changes to support them. 5G presents the same type of potential for sea change that will open up a whole new world of innovations for the consumer and the enterprise.

July 26, 2022
Reducing Energy Consumption With Cloud Cost Efficiency

A new study from Stanford University found that it takes 75 gigajoules per year of energy for a person to have a good, long life, but the average American uses nearly four times that amount: 284 gigajoules/year. In fact, the U.S. consumes 17% of the world’s energy while accounting for only 4% of the population.

It’s not a new call to action that we need to do more to reduce our energy consumption. Corporations are starting to take action by implementing environmental, social and governance (ESG) programs. However, digital infrastructure is a huge contributor to energy utilization. The collective cloud now has a bigger carbon footprint than the airline industry. So, when enterprises are evaluating and managing cloud costs, they have to look beyond the economic costs and also consider the environmental cost and potential harm to the planet—they have a responsibility to use cloud services efficiently with zero waste.

So, the questions to ask are: How do you know if your organization is using the cloud as efficiently as possible, and how do you prove the software you’re developing is cloud-efficient? An organization can have a major competitive advantage if they make cloud cost efficiency a priority for all teams involved—especially given the ongoing climate crisis and current market downturn. Below are three basic rules to ensure continuous cloud cost efficiency.

1. Pay For and Use Only What is Needed

The cloud is a service that gets turned on and off, like a light switch. And, like a light switch, it should also be turned off when not in use. Also, as is the case with separate bins for trash and recyclables, organizations shouldn’t reserve large instances when a medium-sized instance will be acceptable. How much cloud is required will change over time, but it’s rooted in knowing who—which team, application, etc.—is using which cloud resource for what purpose at any given time. Ideally, no cloud resource should be left untagged and no cost unallocated, even for shared resources. Organizations can then focus on eliminating unused and underutilized resources.

2. Understand the Impact

Take advantage of tools that measure the carbon footprint of cloud usage. When organizations can reduce their footprint, it saves money and impacts other business metrics, such as cost of goods sold (COGS), employee satisfaction and even customer experience. Experiment with different technical levers and see how they impact the cloud costs—this will also lead to smarter choices. By empowering engineering teams with cloud cost data, organizations will enable greater efficiency from the beginning of the software development life cycle.

3. Cultivate Conscientiously

Cloud consumption will increase as a business grows—but is it growing efficiently? According to the Flexera 2022 State of the Cloud Report, optimizing usage is the top cloud initiative for the sixth year running, as cloud costs can spiral out of control quickly for a growing SaaS business. With accurate budgeting and forecasting capabilities, organizations can take advantage of long-term savings plans and reserved instances with confidence. In addition, addressing cost anomalies quickly will assist in the stabilization of growth. Not to mention the fact that cloud cost management products offer automated recommendations; the faster users act on cost-cutting alerts, the more money and energy will be saved in the long run.

When an organization is reviewing cost reports and deciding which infrastructure changes to make, they should also give engineering teams real-time visibility and control over cloud costs so they can act faster and more ethically. With a corporate focus on cloud cost efficiency, organizations can brag about their reduced carbon footprint and be confident that their “Go Green” attitude is benefiting customers, employees and shareholders and, above all, the planet.

July 22, 2022
Atlassian Bitbucket CI/CD Cloud Service Aims for the Enterprise

Atlassian today outlined its strategy to increase the appeal of the Bitbucket continuous integration/continuous delivery (CI/CD) cloud service among enterprise IT organizations. Atlassian said it plans to focus on four core pillars: Performance, management, extensibility and security and compliance, starting with an update scheduled for the third quarter.

Dan Tao, head of engineering for Bitbucket Cloud and Compass at Atlassian, said the overall goal is to make it simpler to use the Bitbucket Cloud service running on the Amazon Web Services (AWS) cloud at scale as organizations increase the rate at which they build and deploy software.

Atlassian is still supporting the Bitbucket Server and Data Center editions of the platform, but it’s apparent more organizations are shifting software development to the cloud, he noted. Atlassian is now moving to not only simplify migrations to the cloud by, for example, providing a Bitbucket Cloud Migration Assistant tool, but it is also moving to ensure applications can be developed at scale.

Achieving that goal includes making use of a more advanced diff algorithm that is four times faster in larger DevOps environments, he added.

Other planned enhancements include the ability to execute CI/CD workflows via Bitbucket pipelines, the ability to reuse multi-step pipelines across repositories, tighter administration integration with other Atlassian applications, the ability to encrypt data at rest and integration with the Snyk tool for discovering vulnerabilities in software to improve security.

Finally, the Bitbucket Cloud service will also soon support Bitbucket Mesh, a distributed storage capability that is already employed in Bitbucket Data Center.

Overall, Atlassian sees the migration to the cloud as a means to not only make DevOps workflows more accessible to a wider range of organizations, but also give organizations that have already invested in DevOps the opportunity to streamline those processes, said Tao.

Many DevOps teams today maintain complex platforms with custom integrations that they need to maintain and support. Atlassian provides DevOps teams the option to either employ an integrated platform or use connectors it has created as part of the Atlassian Open DevOps framework to make it simpler for teams to use whatever mix of tools they prefer, he added. In either case, the total cost of maintaining a DevOps environment can be significantly reduced, said Tao.

It’s not clear to what degree organizations that have already invested in DevOps are considering replacing their existing CI/CD platforms. However, as the pressure to accelerate the rate at which software is built and deployed steadily increases, the pressure to further automate DevOps workflows also builds. At the same time, DevOps teams are now being asked to integrate security gateways that require additional custom integrations within legacy platforms that they would need to support alongside existing integrations.

At the very least, more organizations than ever are weighing their DevOps options. The issue, of course, is that the total cost of switching out DevOps platforms is not inconsequential given the current dependency on existing workflows.

July 19, 2022
Survey Reveals High Cost of Application Modernization

A survey of 250 software developers and architects in the U.S. found nearly three-quarters of respondents (74%) reported that the average cost of an application modernization project is nearly $1.5 million, with 79% noting that at least one of these projects has failed.

Conducted by Wakefield Research on behalf of vFunction, a provider of a platform that automatically converts monolithic applications into microservices, the survey polled developers and architects at organizations with 5,000 or more employees that have been in business for at least 15 years and are maintaining Java applications. The survey found that the primary reasons application modernization projects failed were expectations not being set correctly (43%) and the need for organizational structural changes (37%).

Despite the cost and inherent risks, however, the survey also found a full 92% of respondents planned to or are currently modernizing applications. Nearly two-thirds (62%) said having the right resources and tools is the key to application modernization success.

Well over half of the respondents (58%) also noted that, on average, it takes 16 months to complete these projects, with more than a quarter (27%) noting it takes two years or more. Not surprisingly, a full 97% said they expected someone in their organization would push back on a proposed project.

Application modernization, of course, is something of a catch-all phrase that can involve everything from providing applications with a web frontend to lifting-and-shifting them into the cloud or completely refactoring them to run natively on a cloud platform.

vFunction CEO Moti Rafalin said that regardless of the scope of the initiative, most organizations should first pick these projects based on what makes the most sense for the business. Once identified, it then becomes critical for IT teams to have a deliberate strategy in place to achieve that goal given the high cost of failure, he added.

Organizations would also be well-advised to determine how job roles will evolve, because one of the biggest inhibitors to application modernization is concern over how any job might be impacted, noted Rafalin.

It’s not clear how quickly organizations are opting to modernize existing applications versus replacing them outright. However, as more organizations opt to run applications in the cloud, the level of interest in using microservices to build applications has risen sharply. The goal is to employ microservices to make applications both more resilient and secure. The tradeoff is that microservices-based applications tend to have lots of dependencies that make them more challenging to manage and secure.

Regardless of approach, it’s more a question of when an application will be modernized or retired versus if. The level of technical debt that accrues over time for each application eventually becomes unsustainable. The issue, of course, is that most organizations don’t have the resources required to modernize every application at once, so it may take a decade or more to work through an entire application portfolio—even as that portfolio continues to grow. In fact, as technologies continue to evolve, it may turn out that application modernization is not a task to be completed as much as it is a permanent state of IT affairs.

June 29, 2022
Survey Sees Alternative Cloud Service Providers Gaining Ground

A survey of 458 development professionals, managers and senior leaders conducted by Techstrong Research, a sister entity of devopsy.kinsta.cloud, found 43% are considering adding additional cloud service providers in the next 12 months. In total, nearly two-thirds said they are at least considering, evaluating or are ready to buy from a trusted alternative cloud vendor, with 20% reporting they have already contracted one.

The survey, conducted on behalf of Linode, an arm of Akamai Technologies that provides cloud services, found a full 93% of survey respondents are already using either Amazon Web Services (AWS), Microsoft Azure or Google Cloud Compute Platform (GCP). Nearly two-thirds (65%) reported they already used more than one cloud service provider. More than a quarter (28%) said they are using alternative providers to augment services they consume from either AWS, Microsoft, Google, Oracle, IBM Rackspace or Alibaba. And 19% said they are using a hyperscaler and an alternative cloud service provider.

The biggest drivers respondents cited for using alternative providers are reducing reliance on a single provider (55%), improved price/performance (38%) and recent cloud outages (31%).

Respondents also said they are concerned that large providers might one day compete with them as they expand their reach into other industry segments (24%) or may engage in business practices that would create a moral conflict (19%). A quarter (25%) said they already viewed their cloud service provider as a competitor.

Dan Kirsch, principal analyst for Techstrong Research, said as cloud computing continues to mature, it is becoming apparent that more organizations are considering their options when it comes to consuming commodity compute, storage and networking services. Many organizations simply don’t need to access complex cloud services, he noted. A total of 42% of respondents said a cloud service provider offering core infrastructure primatives could handle 90% of their typical workloads. In many cases, alternative cloud service providers are being used to augment rather than replace a hyperscale cloud service provider, noted Kirsch.

Overall, nearly three-quarters of respondents (74%) said they expect their infrastructure will be cloud-based by the end of this year. Nearly three-quarters of respondents buy cloud services directly from an infrastructure provider, with the rest employing a managed services provider or some other type of third-party cloud services reseller.

More than one-third of respondents also reported using a payment mechanism other than a contract or request for proposal (RFP), according to the study. Among customers of alternative cloud providers, more than two-thirds (67%) are using some other payment mechanism, with one-quarter using cryptocurrencies to pay. That option is becoming increasingly important because more organizations are looking for ways to reduce costs by employing alternative payments, said Kirsch.

In other cases, IT professionals are looking for an end-run around cumbersome purchasing processes or simply opt to use alternative payment methods as a matter of personal preference, he added. Alternative providers, as a general rule, are more open to processing these types of payments, noted Kirsch.

The shift to the cloud has clearly been accelerating since the start of the COVID-19 pandemic. But as the landscape continues to evolve, there are now more options than ever for IT organizations to consider as the cloud becomes the preferred platform on which to deploy applications.

June 23, 2022
Four Steps to Avoiding a Cloud Cost Incident

The recent Flexera 2022 State of the Cloud Report found that organizations waste 32% of their cloud spend, up from 3o% last year. This can be due to cloud cost incidents triggered by unused resources, malicious activity or overambitious projects and which have a massive financial impact if not found and corrected promptly.

As an organization’s cloud infrastructure footprint matures, mapping cloud resource use and costs accurately to product lines, teams and business units becomes progressively more complicated and problematic. However, accurate cloud cost attribution is vital to understanding team resource use and determining accurate cost of goods sold (COGS) margins and is imperative to budgeting and forecasting. Organizations need reliable, granular views of the cloud environment to attribute costs back to departments and optimize a meaningful budget.

Cloud cost spikes can blow up an organization’s budget fast and can be hard to track down, but enterprises can help protect themselves from a cloud cost incident with just a few simple steps.

Have a Strong Tagging Strategy That Attributes Cost Granularly

The cloud operations team needs to identify what is important to business reporting, which will help define and create a strategy for tagging. For instance, when an organization has two teams managing a particular service, the teams should safeguard the services tagged with a team identifier. Also, the teams should add another tag for the environment in which they’re running so they can allocate cloud costs across teams and environments.

When an application uses numerous resources, like a database and storage, teams should consider adding a specific application tag and break down costs by each application. It should be noted that there is no one-size-fits-all tagging solution, so enterprises will need to determine what works and try out different strategies by adding and removing tags later.

Understand Cloud Cost Ownership to Avoid Chaos

Ask yourself how well your organization has attributed cloud costs to teams, applications or COGS. If the answer is “Not well,” then you are missing vital information about how your cloud costs relate to your business.

The lack of this context or visibility into resource allocation makes it unmanageable and impossible for cloud operations owners and senior leaders to agree on who is responsible for varied expenses and resources. Manual cost attribution doesn’t scale accurately or account for shared cluster resource use across teams and applications. This creates confusion that can escalate when users arbitrarily slice data and claim ownership without accountability or clear visibility.

What happens is that costs can sometimes be double-counted with two owners—or even missed completely with no owner whatsoever. The resulting data emerges as an inferior quality that is untrustworthy and not actionable. The inability to visualize resource use in context can dilute, hinder and even defeat cost improvement initiatives and optimization.

Cloud costs should have an owner who can ensure that cloud spending is tied to business value. Understanding who owns which pieces will help pinpoint the cause.

Establish and Monitor Cloud Budgets

Historical data on cloud spending is gold—it can help forecast and budget for what should be happening with the cloud’s cost footprint. If that’s not happening, then it should be flagged and investigated.

Once you get cost data under control, organizations can get an accurate picture of where cloud spending is taking place. However, does this match the expectations of spending? By establishing and monitoring budgets at every stage of a project, organizations can have guardrails to cloud spending and prevent costs from soaring out of control when engineers overallocate on performance “just in case.” Once budgets are in place, organizations can monitor spending and right-size resources to balance actual usage, rather than estimated usage at the start of execution.

Over time, right-sizing resources will allow for optimal spend, as well as identify unused resources that can be shut down. Organizations should identify development and test instances left running when no longer needed and shut them off.

Implement Cost Anomaly Detection

Organizations can shield themselves from cost anomalies by continually monitoring and optimizing cloud costs. Cost anomaly detection can help act as a barrier to early recognition before they become problematic. This is especially effective when prompt, actionable alerts can be delivered directly to resource owners via Slack or email when their forecast exceeds the set budget. The best option would be adopting a cloud cost monitoring and optimization (CCMO) tool that gives alerts in real-time when a cost anomaly occurs. These tools must be able to detect anomalies and analyze their root cause, while also allowing visibility into what went wrong to avert similar future errors.

Executing continuous cost monitoring and anomaly detection tools for dynamic cloud environments is essential in identifying any activity that doesn’t align with expected expenditure or diverges from an established pattern. With proper monitoring, organizations can take corrective measures before the fact.

Unwanted and unexpected cost incidents can clean out an enterprise’s budget quickly, especially as its cloud infrastructure grows. Organizations need to practice these steps to gain a full picture view of their cloud environment.

June 22, 2022
Could Buying VMware Bring Broadcom Hybrid Cloud Bona Fides?

Rumors are swirling that Broadcom wants to buy its way into the growing hybrid cloud market by acquiring VMware. The deal won’t come cheap—after news of the potential deal surfaced, VMware’s market cap soared to around $50 billion. Yes, billion with a ‘B’.

As interest rates increase and investors reevaluate many of the lofty software company valuations, I expect to hear many more acquisition rumors. During this time of uncertainty, cash-flush vendors are going to be on the hunt for software vendors that can provide a technology platform, have large partner ecosystems and that also produce reliable revenue.

Why the Acquisition Makes Sense for Broadcom

Broadcom has a nice, solid business producing semiconductors for smartphone makers as well as storage and networking devices used in large data centers. However, like many hardware companies, the business has been desperately trying to break into the software industry. Why? There’s a semiconductor shortage and the company is in the right market at the right time. However, the company’s leadership knows that market conditions change. Software margins are significantly higher than hardware deals, and R&D and manufacturing costs for semiconductors are notoriously high.

VMware has grown to become a large cloud technology platform, not just a virtualization offering. If Broadcom is able to successfully close on this deal, it will instantly own one of the largest cloud software platforms in the industry. In addition to acquiring large enterprise customers, the VMware partner ecosystem is important. For example, I believe that the NVIDIA partnership will be a profitable one for VMware. The two companies have been working together to create a platform to support AI-based applications for the data center, cloud and at the edge.

In a time when some cloud businesses are experiencing wild fluctuations because of their lack of profitability, the VMware business model is solid. However, these fundamentals are also why the company is ripe for acquisition. In its fiscal year 2022, the company reported $12.85 billion in revenue and $6.33 billion in subscription and SaaS licensing revenue. Free cash flow for fiscal year 2022 was nearly $4 billion.

Let’s quickly contrast VMware to the cloud data warehouse Snowflake (NYSE: SNOW). Snowflake’s market capitalization is around $40 billion and within the last year was well over $120 billion. Meanwhile, the company’s revenue is around $1.2 billion and it is struggling to find a path to profitability. If you were hunting to acquire a software business during a time when financial indicators are flashing red, which business model would you prefer?

Broadcom’s Strategy: Become a Software Company

I mentioned that Broadcom is desperate to gain relevance in the software industry. Why do I say this? The company’s recent acquisitions showed a clear pattern emerging—Broadcom has been trying to acquire its way into software.

In 2018 the company acquired CA Technologies for nearly $19 billion. The following year, Broadcom acquired Symantec’s enterprise cybersecurity business for $10.7 billion. In addition, there were rumors that Broadcom was planning to acquire SAS Institute, the privately held analytics vendor, for somewhere around $15 billion to $20 billion. Those talks fell through when the SAS Institute’s aging co-founders and majority stakeholders announced a plan to go public in 2024.

This M&A strategy might seem strange to many, but Broadcom originally tried growing through the acquisition of companies similar to itself. In 2018, the company made an offer of $117 billion to acquire chip producer Qualcomm. Broadcom later withdrew the bid when it became clear that the Trump administration pushed hard to prevent the deal, citing national security concerns.

Although this latest deal would face governmental review and the Biden administration previously voiced concerns over tech mega-mergers and monopolies, we have not seen the administration prevent similar deals.

The Path Won’t be Easy: Three Strategies for Success

The market is full of cautionary tales of software vendors that were acquired only to be slowly destroyed. A successful acquisition would require Broadcom to tread lightly and maintain the elements that have made VMware the company that it is today. Below are three priorities that Broadcom should focus on if the deal is completed.

Keep VMware independent: It is critical that VMware does not show favoritism toward one chip maker. VMware’s largest customers use chips from Intel as well as other manufacturers. If Broadcom tries to steer VMware toward its own chips exclusively, the backlash could quickly undercut the value of the acquisition. In addition, it’s my belief that the hybrid and multi-cloud models are here to stay (rather than a single cloud approach). Customers expect vendors to work with each other and are reluctant to accept single stack proprietary approaches.

Find innovative DNA and facilitate business unit collaboration opportunities: Hock Tan, Broadcom’s CEO, is very well respected in the industry; however, the company is not known for software innovation. Although I expect VMware to remain a standalone business unit (similar to CA’s current position within Broadcom’s ecosystem), it will be important to foster innovation. Broadcom should accelerate VMware investments, like Project Monterey and the NVIDIA partnership, while looking for new investment opportunities. Perhaps Broadcom could provide VMware with custom chips to help accelerate Project Monterey, but this sort of line-of-business collaborative innovation hasn’t been the model for Broadcom’s other software acquisitions. It should be.

Nurture the partnership network: The next phase for the VMware partner ecosystem will require partners to understand the company’s vision for the future. What will the acquisition mean for partners? Will they have access to more solution selling that combines VMware and Broadcom technologies? How can existing Broadcom partners join the VMware partnership ecosystem? That will be another big question.

It will be extremely interesting to see how this plays out. We’ll definitely be keeping an eye on this potential merger of two heavyweights!

May 24, 2022
Survey Surfaces Challenges Ahead on National DevOps Day

A survey published today for National DevOps Day found nearly two-thirds (63%) have seen an increase in the frequency of service incidents that have affected their customers over the course of the last 14 months.

The survey polled 1,046 engineering, IT operations, DevOps and site reliability engineering (SRE) professionals at organizations with more than 300 employees. The research was conducted by Transposit, a provider of a platform for connecting DevOps workflows, and found well over half (58%) of respondents reported the cost of downtime for their organization could be, on average, up to $499,999 per hour, with 40% of respondents noting that the cost of downtime has increased in the last year.

Respondents said the top contributing factors to the increase in service incidents were digital transformation (61%), new product rollouts or product updates (55%) and methods and tools for collaboration that do not adequately support their team working remotely (49%). A full 90% of respondents reported there has been an increased focus on digital transformation during the last year with 73% having expanded the technology stack they support. More than half (55%) have increased the size of their DevOps teams.

Overall, 46% of organizations reported they have experienced between six and 19 major incidents over the course of the last 12 months. More than half (53%) also reported an increase in the amount of time it takes to resolve incidents over the course of the last year, even though three-quarters of respondents (75%) said their organization increased their adoption of SRE practices in the last 12 months. Additionally, 65.1% of those organizations planned to hire site reliability engineers in the next 12 months. However, only just over a third of those respondents said their organization planned to expand their SRE efforts in 2022.

A full 83% said up to 50% of their engineering operations processes are automated, but over half of the respondents that use SRE practices noted they still manually enter data into an IT service management (ITSM) application or other system-of-record to keep track of actions that were taken by humans during the resolution of an incident. Nearly two-thirds said their approach to automation was incremental, in which they begin by codifying processes and worked up to more advanced, fully automated scenarios.

The top three tasks respondents would like to automate were service requests (53%), change requests (43%) and user provisioning (40%).The top barriers to implementing automation were cited as inadequate documentation of institutional knowledge and existing processes (56%), lack of clarity about what to automate (55%) and an inability to share knowledge (52%).

Investments to improve their incident management processes over the next 12 months are focused on automation tools or applications (48%), communications/collaboration tools or applications (42%) and integration tools or applications (41%). Only a quarter (25%) said their tools are integrated through one tool or platform.

Lack of unified communication with teammates (45%), processes that have changed or are harder to follow while working remotely (42%) and lack of visibility into dependencies and what teams or people are responsible for the code or infrastructure (38%) are all cited as reasons why serviced requests are now more complex.

Transposit CEO Divanny Lamas said despite all the challenges facing DevOps teams, it’s fortunate that advances in low-code automation are making it simpler to more widely implement DevOps best practices. The challenge is finding a way to implement those best practices faster at a time when IT environments are becoming more complex.

May 24, 2022