devopsy.kinsta.cloud

Category: DevOps in the Cloud

How the Cloud is Reshaping IT

The cloud has been rapidly reshaping and redefining IT as we know it, from the language we use to describe it to the management models and infrastructure itself. Providers such as Amazon Web Services, Google Cloud Platform and Microsoft Azure have transformed cloud computing, giving businesses access to IT resources anytime, anywhere. At the same time, this rapid migration off-premises has been reshaping the needs and roles in the IT department.

The Cloud and IT

The following are four ways that the cloud is redefining IT roles and operations:

Sysadmin vs. DevOps

When you compare sysadmin vs. DevOps, you’ll find that they’re similar roles, but also distinct. A system administrator, or sysadmin, is the person responsible for configuring, operating and maintaining computer systems, servers in particular. This jack-of-all-trades IT role handles everything from installations and upgrades to security, troubleshooting, technical support and more.

And then we have the evolution of DevOps, which could very well be the biggest game-changer to the IT process. Under the DevOps umbrella, a team of software developers, IT operations and product management people must combine strengths to effectively streamline and stabilize operations for rolling out new apps and updating code to support and improve the whole business.

With the cloud taking over and without the need for physical, on-prem servers, a large portion of the sysadmin role has become lost to automation. As this change was occurring, sysadmins remained effective as their role shifted toward the support of developers, combining efforts and thus giving birth to the term DevOps. So, can you truly compare sysadmin vs. DevOps? Well, the roles are similar in the sense that sysadmins can do a lot of what DevOps guys do, but not the other way around, making DevOps the newer, bigger jack of all trades.

IT Operations Management vs. Cloud Operations Management

IT Operations Management is responsible for the efficiency and performance of IT processes, which can include anything from administrative processes to hardware and software support, and for both internal and external clients. IT management sets the standard policies and procedures for how service and support is carried out and how issues are resolved.

Thanks to the cloud, IT management has also given way to automation and outsourcing. Cloud operational processes are now a more efficient way of using resources, providing services and meeting compliance requirements. In the same way IT operations and projects (ITOP) manages IT processes, cloud operations management is doing so in a cloud environment with resource capacity planning and analytics that provide vital intelligence into how to control resources and run them cost-effectively.

IT Service Management vs. Cloud Service Management

Traditional IT service management (ITSM) dealt with strategizing in the design, delivery, management and innovation of the way an organization is using IT. This involved developing, implementing, and monitoring IT governance and management using frameworks such as COBIT, Microsoft Operations Framework, Six Sigma and ITIL, for example.

As the cloud became a better option for operational management, companies have turned to it to transform their business model via service providers including Amazon Web Services, Google Cloud Platform and Microsoft Azure to outsource IT for more efficient, scalable services.

Since cloud computing resources are hosted as off-site VMs and managed externally, ITSM has grown more complex, introducing cloud service management (CSM) as an extension of ITSM, pushing in three core areas: automated service provisioning, DevOps and asset management. And as ITSM shifts toward CSM, the concerns lie in the adoption strategy and the approach for designing, deploying and running of cloud services.

Finance and Operations vs. DevFinOps

In a world where IT projects are known to exceed budgets and coming up with cost estimates is no easy feat, how can businesses break down a reasonable overall estimate for projects in which applications are developed, built and run on a utility? The answer is to make estimates little by little as parts of the work get completed, integrating financial planning directly into IT development operations. In other words: DevFinOps.

IT asset management (ITAM) merges the financial, contractual and inventory components of an IT project to support lifecycle management and strategic decision-making. The strategy involves both software and hardware inventory and the decision-making process for purchases and redistribution. DevFinOps expands and builds upon ITAM by fixing financial cost and value of IT assets directly into IT infrastructure, updating calculations in real time and simplifying the budgeting process.

What This Means For You

Cellphones, self-driving cars, DevOps … cloud computing is yet another evolution in technology—albeit a huge one—and IT is simply going through a metamorphosis. The best way of looking it at is that cloud is not killing IT, it’s redefining IT. Enterprises are following suit as they make the shift and change or update traditional IT roles. As IT evolves, the cloud is paving the way for opportunities for those who adapt and evolve their roles with it.

— Jay Chapel

March 12, 2018
VMware Adds More DevOps Depth to Cloud Strategy

VMware today added a bevy of services to its portfolio that make managing instances of its software running in a public cloud easier.

Additions to the VMware cloud portfolio include VMware Hybrid Cloud Extension Service for Private Cloud, a software-as-a-service (SaaS) offering that enables IT organizations to employ a self-service portal to move workloads between public clouds in a way the minimizes downtime.

Other additions include the ability to apply both the Wavefront by VMware monitoring service and VMware Cost Insight Service against VMware Cloud on AWS, in addition to other public clouds. VMware has also added 45 integrations to expand the number of processes this SaaS application can monitor.

Finally, VMware has added a VMware Log Intelligence Service to provides access to real-time analytics of log data.

The arrival of these services coincides with the availability of VMware Cloud for AWS in the London region of AWS, which will be followed by the VMware stack becoming available in the Frankfurt, Germany, region of the AWS cloud.

Chris Wolf, vice president and CTO of global field and industry for VMware, said that as more organizations look to move out of data centers they operate, they are asking VMware to extend the mobility capabilities the company developed for its hypervisor into the public cloud. In fact, many of them are now moving to deploy VMware software across multiple clouds, he said.

Naturally, that expansion of VMware beyond the local data center is creating a raft of DevOps challenges, many of which the company is trying to address by making available a series of SaaS applications under the moniker VMware Cloud Services.

VMware is making a concerted effort to expand its DevOps portfolio at a time when many developers have shifted application workloads onto public clouds based on virtual machines other than VMware. Obviously, VMware has developed many partnerships with cloud service providers. But the number of VMware hypervisors running in public clouds remains a relatively small percentage of the total number of hypervisors. VMware is hoping that will change, however, once developers discover VMware hypervisors on public clouds, which in many cases can reduce the headaches associated with trying to manage hybrid clouds based on disparate hypervisors. As part of that overall strategy, VMware also has been aggressively embracing emerging cloud-native platforms such as Kubernetes that can run anywhere.

Most enterprise IT organizations are still learning to walk when it comes to hybrid cloud computing. The most common use case is still disaster recovery. Most IT organizations are a long way from dynamically moving workloads between clouds. Most of the use cases for moving workloads initially will be confined to simply lifting a workload from an on-premises environment. But as IT organizations also gain more experience, soon there may be as many workloads moving between clouds as there are workloads moving between servers in a local data center.

— Mike Vizard

March 7, 2018
How a Visual Cloud Management Platform Can Address DevOps Woes

DevOps and cloud are a match made in heaven. However, the advantages of the cloud are apparent only when continuous deployment, development, operations and other DevOps tasks can be performed and automated seamlessly on the cloud. Moreover, many of today’s cloud management platforms do not offer much cross-functional visibility, something DevOps engineers require.

A visual cloud management platform can be the answer to ensuring DevOps thrives in a cloud environment. Here are few use cases that highlight how a visual platform can solve a DevOps engineer’s woes:

Partial Visibility Due to Use of Siloed Infra Management Tools

There are scores of infrastructure-as-code (IaC) and infrastructure automation tools available, with choices for server provisioning, configuration management, automated builds, code deployments, intraservice orchestration and more, from companies including Ansible, CloudFormation, Terraform, Puppet and Chef. But there’s no single tool that meets all needs. At the end of the day, DevOps engineers need to use and manage dozens of siloed IaC tools that help deploy and manage an end-to-end tech stack.

Customizing a tech stack to meet the engineer’s needs—choosing from Docker Swarm or Kubernetes, MySQL or Postgres, Jenkins or CircleCI, and so on—can be overwhelming. Figuring out how to run the code in dev; how to build and test; how to deploy changes; where to find metrics, logs, and alerts; and so on across several tools is easier said than done.

While each orchestration tool provides multiple benefits, engineers also must juggle between multiple dashboards cloud service providers (CSPs) offer. As cloud use increases, complexity and partially visibility are bound to happen, making it difficult to make sense of resource usage and perform root-cause analysis. And if the infrastructure is on a multicloud setup, chances are teams/engineers will lose visibility of resource usage.

A siloed approach to infrastructure management using multiple dashboards is a big ‘no.’

Solution: An interactive and immersive visual cloud management platform provides visibility across resources, apps, tools, etc., with a complete context of resource usage from a single pane of glass. The visual console must be visually rich and intelligent enough to provide context-aware real-time prescriptive insights and help with operations on a topology view.

Visualizing Auto-Scaled Containers and Clusters of Containerized Deployments

Containers are great for making DevOps workflows easier. Their ability to run almost any type of app has made it popular. Today, there are several container orchestration tools available with autoscaling, including Kubernetes. However, when there are large numbers of clusters of containerized deployments, inspecting or monitoring nodes, pods and containers for optimization, cost reduction and handling system malfunctions can get overwhelming.

Solution: A visual cloud management platform can show containers and its subcomponents in a relationship view with other cloud resources on a live topology view. Such a tool will help DevOps engineers investigate anomalies quickly and easily.

Difficulty in Implementing Resource Dependency Mapping an SDN in a Hybrid Cloud Setup

Software defined networking (SDN), which enables network automation, is typically difficult to define for DevOps, especially in a hybrid environment. Extending network capabilities or automating the network to update itself when there is a change requirement can be quite challenging in a hybrid setup. The need of the hour is a language, such as JSON or XMPP, that will draw dependency mapping and automate network flow with the cognizance of a human.

AWS and other public cloud service providers provide basic-level dependency mapping. However, a DevOps engineer loses visibility across resource usage when a business has a chunk of SDN components integrated with dozens of resources on the public cloud or in multicloud or hybrid cloud environments.

Solution: A visual cloud management platform can map resource dependency on a live topology automatically, analyze and define further network connections and automate operations. With such a tool, a DevOps engineer can easily understand the underlying interconnection, understand the entire infrastructure in a snap and keep the infrastructure hail and healthy.

Finding Unused DR Environments to Maximize Infrastructure Usage

Increasingly, DevOps engineers are using backup capacity as development environments to maximize their infrastructure investment. Disaster recovery (DR) environments represent an ideal workspace for developers to test their code with the help of virtualization technologies and advanced networking. However, mapping all the tool integrations and finding that extra capacity in an ever-changing multicloud or hybrid cloud environment can be challenging.

Solution: A visual cloud management platform can provide visibility into third-party integrations on your cloud and also show any backup capacity available for development use.

Immersive Visual Consoles Becoming the New Normal

A visual cloud management platform that helps DevOps engineers get a complete and viewable context across cloud services, network flow and topology view of the entire infrastructure from a single pane is the way forward. Such a platform is the solution to solve several DevOps woes. It enables visualization of public/private cloud services and third-party integrations, giving engineers the ability to understand the resource and network relationship in real time; get a complete perspective of infrastructure; perform contextual monitoring, cloud operations, root-cause analysis in a snap; and ensure security and compliance from one place.

Let’s look forward to a world in which using these immersive visual consoles will be the new normal.

— Pradeep Kumar

March 1, 2018
‘Software is Eating the World,’ and DevOps Needs a New Infrastructure to Keep Up

Every Fortune 1000 company should expect to face Uber-like competition in the next decade. These digital disruptors are software companies; they are basing their business models on software platforms, and development of these software platforms is much more agile than in the past. To compete effectively, every company must essentially become a software company, and it must adopt agile software development practices to keep up with the demand for new applications and services.

Software Development: The Engine of Digital Transformation

Digital transformation will be the mantra for IT initiatives in 2018, and the underlying technology will be agile software development. IT organizations are at a crossroads: They can either work to become more agile and innovative, or business unit managers will decide to expand their use of public cloud providers, reducing the role and value of internal IT organizations.

Applications are defining and continuously redefining products, services, customer experience, business processes and competitive advantage. About the only thing not being redefined by applications is the IT infrastructure. As applications and organizations become more dynamic, IT largely operates at the pace it always has. High-velocity DevOps life cycles collide with an IT infrastructure that is optimized for stability and is too complex to keep up. The pace of the organization is slowed down by its applications, while the pace of applications is slowed down by their infrastructure.

How DevOps’ Role is Changing

For decades, DevOps organizations have been at the mercy of IT departments, having to request resources for development efforts. DevOps groups have endured long provisioning cycles, waiting days or weeks for IT to provision servers, databases, development tools and other resources. Even the tools for requesting resources are antiquated—most IT departments rely on manual ticketing systems that require requests to be passed from one silo to another before a request is completed.

But with software development as a corporate priority, companies are now looking for much more streamlined development processes. DevOps now wants to drive the provisioning process. This has given rise to a lot of ad hoc use of public cloud resources by DevOps teams. No longer content to wait for the IT department to provision resources, DevOps organizations are taking control away from the IT department and are provisioning resources themselves with public cloud services such as AWS, Azure or Google. These platforms have enabled agile software development, and the spread of agile software development is integrating development and deployment into a unified continuous integration/continuous development/continuous deployment (CI/CD/CD) process. In the meantime, the IT department wants to maintain control over the infrastructure and software tools in use, as well as the monthly spend on public cloud resources.

Unfortunately, what began as a fast, ad hoc way of acquiring compute resources from the public cloud has become a significant drain on enterprise resources. Monthly cloud costs are spiraling, and the IT department has little control over these expenditures. In many ways, DevOps has usurped IT’s role in resource provisioning. Also, it’s easy to create a sprawling, undisciplined IT environment where the company is not sure which workloads its developers have on AWS or other public clouds. Finally, the company may be developing applications that use intellectual property or confidential client information—or require high security or government compliance—so using public clouds for DevOps may not be an option.

What Developers Want

Clearly, today’s DevOps teams want to be able to select and provision resources as needed. They want to be free to build their own workspaces without waiting for provisioning by the IT department. If cloud platforms accelerate the application life cycle by applying new technology to operations and integrating and aligning applications and infrastructure, the challenge for IT is to regain control over the process. The answer is to deploy a private cloud platform that is as easy to operate and consume as a public cloud. With a self-provisioning private cloud platform, DevOps teams can continue to set up their own workspaces and access the tools they need to complete their development cycle, and IT’s private cloud—rather than a public cloud provider—makes those resources available.

Compared to public cloud, private cloud delivers improved security and governance, higher performance and lower costs. It also unifies the separate compute, storage and networking silos to deliver a cost-optimized IT infrastructure. With a private cloud, DevOps can have the agility it needs while IT retains the control it needs. It’s a win-win for both groups.

— Ajay Gulati

February 28, 2018
Why an Enterprise 5-Year Cloud Plan Must Focus on Serverless
While most of us have looked at the beginning of the new year as the time to set our personal resolutions for the next 12 months, enterprises have already started to execute their plans for the year ahead. But, that’s part of a problem. Too often major organizations move from year to year on a schedule of 12-month technology plans, never really planning or setting a path for ambitious change that will be realized in years two through five. Thinking in terms of 12-month plans, rather than a desired end state in three or five years, creates a missing-the-forest-for-the-trees effect, where enterprises can end up chasing the technology trend du jour and miss taking advantage of major disruptions to their industry.

We saw this with the cloud: Many enterprises, still focused on improving virtualization, were surprised by how quickly their developers took to the cloud to develop new applications. These same organizations have factored the cloud into their long-term planning now, but only after many others have reaped the advantages and proven it to be a great way to deliver rapid innovation. And, so far, enterprises look to be on the verge of making a similar mistake with serverless computing.

Serverless: The Ultimate Abstraction Layer

Many developers are increasingly looking to serverless computing as a faster way of developing and deploying business IT workloads. It’s not difficult to see why: Developers focus on their application and run it with third-party management; their code is only executed when prompted by predetermined triggers; it scales automatically as needed; and the business is only charged for the time that that code is actually running (as opposed to a flat rate, regardless of whether the code is running). This seems like the kind of intuitive no-brainer that enterprises should be setting a path to now.

Serverless computing is the natural outcome of the past decade of IT development, where we’ve seen different kinds of layers of abstraction being applied to hardware to create innovative new forms of growth, and do so at scale. Those layers run the gamut of:
- Virtualization, used to consolidate multiple virtual machines across a single hardware platform;
- The cloud, used to virtualize compute, networking and storage; and
- Containers, used to isolate application technology components that can be deployed and operated at scale across multiple substrates.
Following that evolution, we now have serverless computing, which takes code and functions, and executes in an environment that takes care of all the underlying infrastructure, everything from application services through operating systems, hypervisors and hardware. In other words, the ultimate abstraction layer.

Embracing Serverless Means Rethinking IT

Previous abstraction layers, such as the cloud and containerization, broke out as disruptive technologies and caught a lot of enterprises flat-footed—they hadn’t been planned for well enough in advance. Organizations needed to adjust to incorporate them into their IT workloads and business models after the fact to try and give their developers what they wanted and avoid falling behind. Consider the disadvantage that places them at when compared to cloud-first—and, increasingly, cloud-only—organizations.

Serverless promises to be even more disruptive, in no small part because it isn’t just a new layer to add on top of your hardware, as containers and the cloud were. Incorporating serverless computing into your IT environment requires a complete rethink of how your IT workloads are structured, because the serverless approach works by forcing organizations to focus on business technology as application code and not be distracted by the commodity services needed around it.

All the more reason why enterprises need to get serious now about making a long-term plan for IT that revolves around serverless computing and outsourcing IT infrastructure. Preparing for a world where the default for new applications is to be developed to run against serverless platforms will take several years. And, in fact, delaying too long will only open you to some of the challenges presented by serverless adoption: application portability, service predictability and overall failure liability.

Enterprises are understandably wary about outsourcing too much of their IT infrastructure, but the fact is, this is the direction the world is moving in. And besides, serverless isn’t solely a service offered by external cloud providers. There are many serverless platforms, such as Galactic Fog, that can be run atop of fully managed Kubernetes or OpenStack on-premises infrastructure and deliver the same benefits. Companies will only continue to outsource more and more of their IT infrastructure one way or another through 2018, putting us on track for entirely serverless businesses in just five years’ time.

While everyone is thinking about the year ahead, enterprises need to think about the next five years, whether their IT infrastructure as-is is making a difference to their business and how they can—and need to—restructure accordingly to best leverage serverless computing to their benefit.

— Mark Baker
February 28, 2018
SAP Cloud Price Changes Reflect DevOps Realities

To foster more application development in the DevOps era, SAP at the Mobile World Congress 2018 conference announced it is adding a consumption-based pricing option to its SAP Cloud Platform environment.

Based mainly on the Cloud Foundry platform-as-a-service (PaaS) overseen by the Cloud Foundry Foundation, the SAP Cloud Platform provides a way for SAP customers to build custom applications that can be more easily integrated with SAP applications delivered as a cloud service using a standard set of application programming interfaces (APIs). The basic idea is to enable organizations to innovate in a way that doesn’t impact their applications every time SAP, for example, updates the SAP S/4 HANA application portfolio, said Dan Lahl, vice president of product marketing at SAP.

SAP Cloud Platform currently is made available via a set of services an organization subscribes to for a defined amount of time. Under the consumption approach, an organization buys credits that can be applied within a specific amount of time. That makes it more economical for organizations to start multiple custom projects without having to know precisely upfront what services will be employed on the SAP Cloud Platform, Lahl said.

In effect, SAP is creating a licensing model more in keeping with how developers consume services in the age of DevOps, he noted.

SAP also announced an enhanced SAP Cloud Platform SDK for iOS, providing tighter integration with the Apple Xcode integrated development environment (IDE) and additional analytics controls that can be embedded within an iOS application. SAP has also made it easier to consume SAP Leonardo services for building internet of things (IoT) applications using APIs that can be accessed via the SAP API Business Hub.

Lahl said in the coming months SAP also will share with customers best DevOps practices it follows to develop and maintain cloud applications. SAP is now seeing traditional IT organizations now starting to more aggressively adopt DevOps processes, he said, primarily because DevOps processes enable IT organizations to show a proof-of-concept (PoC) to line of business executives much faster. That, in turn, also serves to condense the feedback loop between business units and the internal IT team.

Those projects now span multiple classes of runtimes, including SAP ABAP, Java and Docker containers—all three of which are being employed to create microservices. The challenge many organizations now face is determining when to build a microservice versus invoking a function via an API that already exists in an ERP application. Application developers don’t often have visibility into an existing function, which is why they run into resistance from business executives whenever they attempt to reinvent a wheel that already exists, Lahl said. The challengeis making it easier to discover the APIs that expose functions within an existing monolithic application, especially when it doesn’t make sense to reconstruct a general ledger function as a microservice.

Whatever the ultimate approach employed, the one thing that is clear is that costs associated with either building or consuming a service keep coming down in the age of DevOps.

— Mike Vizard

February 27, 2018
Is DevOps Ready for a ‘Steam’ Moment?

It’s hard to believe we live in a world where a game such as “Goat Simulator” can manage to find an audience in an industry brimming with AAA titles including “Destiny 2,” “Overwatch” and “Call of Duty,” but we do. “Goat Simulator” was a massive success, but none of that would been possible in a pre-Steam world.

Before Valve launched Steam Greenlight, and subsequently Steam Direct, the indie game community was a shell of what it is today. The path to market for independent game developers was very limited up until that point, allowing the likes of Electronic Arts, Square Enix and Nintendo to dictate the future of the industry as a whole. While only apparent in hindsight, the state of the market wasn’t only impacting game developers, it was limiting the choices of the gamers themselves.

The state of cloud services today is almost identical to what we saw among indie game developers prior to the launch of Steam Greenlight. Amazon, Microsoft and Google have established a cloud monopoly, but they don’t have a monopoly on innovation. This has forced developers to play by the monoclouds’ rules and live within their walled gardens, sacrificing quality and performance for cost and convenience.

Related Content:

Operations Management Puts the ‘Ops’ in DevOps

Resource Availability: The Missing Piece of the Cloud DevOps Puzzle

This ultimately undermines the prime directive of DevOps, by limiting an organization’s ability to map software investments and architecturing to its business objectives. The phrase “one size fits all” has no place in the world of DevOps, but if Amazon and the other cloud titans have their way, Dev and Ops teams will have no choice but to do their best with an increasingly ubiquitous set of solutions.

Sure, there are breakout success stories among developer service startups including Twilio, MongoDB, New Relic and SendGrid, but for every developer service that manages to get off the ground, there are at least 10 that die on the vine. Why should the future of the cloud, which is arguably the biggest technological advancement since the internet, be shaped by companies known for retail, search and hardware? It shouldn’t.

Developers need their own Steam moment, and it wouldn’t just benefit DevOps teams, it would benefit businesses and make the market more competitive overall. The developer equivalent of “Goat Simulator” is out there, waiting to go viral, except instead of letting you control a four-hooved wrecking ball, it lets you hunt down expensive N+1 queries or configure RabbitMQ clusters.

Get Ready for the Steam Moment

So what does developer’s Steam moment look like? It all starts with discovery.

Developer startups will never be able to compete with the economy of scale that a company such as Amazon possesses. The resources behind AWS allow the company to pump out comparable solutions to emerging developer favorites before they have a chance to reach a mainstream audience, which results in the death of far too many promising startups. Even with superior technology, they simply can’t keep up with Amazon’s spend on sales and marketing, which allow them to manufacture user bases overnight. If we applied this state of affairs to gaming, and Steam hadn’t existed in 2014, games such as “Goat Simulator,” “PLAYERUNKNOWN’S BATTLEGROUNDS” or “Stardew Valley” would have easily been co-opted by a major game studio right when they were on the verge of taking off.

To correct course, cloud service startups need a platform for connecting them with their audience, whether they offer a solution that will be useful to 100 or 100,000 developers around the world. However, to make this possible, developers and operations teams need to gain a voice during the procurement process before their executives make their way to AWS re:Invent to be wooed by flashy sales pitches and $50 steaks.

But, that is only step one. DevOps teams need to do their research and point management toward solutions that reside outside of the monocloud hierarchy. Even if the developer equivalent of Steam exists, that doesn’t guarantee non-technical executives will find it, which is why developers not only must vocalize the solutions they need, but also where to find them. Contrary to popular belief, even if you build it, they don’t always come, and if the developer community remains quiet, we can forget about having our own Steam moment.

I’m glad we don’t live in the timeline where a goat simulation can turn into a viable business, and hopeful our cloud future won’t be dictated by the likes of Amazon and Microsoft. Our Steam moment hasn’t happened yet, but if developer and operations teams join forces to demand a better alternative to the one-size-fits-all approach, it could be just around the corner.

— Peter Cho

February 21, 2018
Top 3 Challenges of Adopting Microservices as Part of Your Cloud Migration

Many organizations embark on cloud migrations to achieve scalability, cost-efficiency and higher application performance. IDC estimates 60 percent of worldwide enterprises are migrating existing applications to the cloud. With the promise of greater flexibility, a reduction in overhead and the potential for significant cost savings, it’s a logical decision. But instead of performing a “lift and shift”—simply moving an existing application to a cloud platform—many businesses use the migration period as an opportunity to modernize the architecture of their applications.

What’s more, in a survey by NGINX, over 70 percent of organizations say they’re adopting or exploring microservices for their new architectures—and with good reason. A complex name for what is relatively a simple concept, microservices refers to a concept whereby individual parts of an application are constructed as discrete, modular building blocks. Breaking a monolithic application into manageable microservices allows development teams to rapidly respond to an ever-evolving set of business requirements, choose the right technology stack for each task, and readily provide support for a variety of delivery platforms, including web, mobile, and native apps.

But with the great benefits that microservices bring, there are also some challenges that enterprises face as they look to adopt new concepts to maintain their competitive edge. In fact, adopting microservices as part of your cloud migration isn’t always easy. Below are three common challenges we’ve seen enterprises face, and solutions to help mitigate these risks.

Challenge 1: Identifying What Needs to be Migrated to Microservices

Before you can begin breaking your application out into individual microservices, you first need to understand its full scope and architecture. This can prove challenging, as many times the overarching view of the application is based on “tribal knowledge” or cobbled together from a collection of disparate tools. Sometimes a more holistic view may be available, but is based on outdated information that does not reflect the current architecture of the application.

Related Content:

DevOps in the Cloud: Security’s Groundhog Day

The Challenges of Digital Experience Monitoring

You need to find a solution that will help you discover and map every component, dependency and third party call of your application. This solution should help you understand the relationship of these pieces and how each impacts your application’s behavior and user experience. Armed with this information, you’ll have a clear picture of what needs to be migrated and will be able to make more-informed decisions regarding the architecture of your microservices.

Challenge 2: Ensuring Your Microservices Meet or Beat Pre-Migration Performance

To ensure your application runs smoothly post-migration, and that user experience was not negatively impacted, you need a way to compare performance metrics from pre- and post-migration. This can be extremely difficult, as the architecture of these two environments (with the changes to hardware and the move to a distributed architecture) can look drastically different. To make things even more difficult, the monitoring tools supplied by individual hosting providers give insight into only a small portion of the entire architecture and have no way of creating a more holistic set of data.

To combat these issues and establish a consistent baseline by which to measure your performance and user experience, you will need to capture key user interactions (often referred to as business transactions), prior to beginning your migration. The business transactions are likely to remain the same through migration whereas other metrics may change as you take different code paths and deploy on different infrastructures. Armed with baseline data about your business transactions, you can easily compare the performance of your pre- and post-migration environments and ensure that there is no impact to your user experience or overall performance.

Challenge 3: Monitoring Your New Microservices Environment

With large, monolithic applications running a single codebase on a few pieces of hardware, two or three tools could once provide complete, straightforward monitoring of application and infrastructure performance. However, with the introduction of microservices and the potential for each service to implement its own solution for technology stack, database and hosting provider, a single service may now require a greater number of monitoring tools than the entire application once did. And microservice monitoring brings specific challenges: They are often short-lived, which means monitoring over a longer period of time can be more complicated, and there may be more pathways through which the service is reached, potentially exposing issues such as thread contention.

Finally, while development teams previously didn’t require a monitoring solution that took infrastructure into account, the move to DevOps and the reliance on cloud-native technologies means this factor can no longer be ignored.

Changes in consumer behavior and expectations have been the catalysts for large tech trends including cloud computing and mobile device adoption. While the change of pace can be dizzying for many, as the need for speed in application development is greater than ever before, cloud migration is possible. The goal for any business looking to successfully adopt microservices as a part of its cloud migration is to find a unified monitoring platform that supports all of your environments, regardless of language or technology stack. This solution must collate metrics from across your application and infrastructure into a single source of truth and allow for correlation of those metrics to user experience.

— Matt Chotin

February 20, 2018
Manage Cloud Clutter with Better DevOps Hygiene

One of the core principles of DevOps is automation. Continuous development, deployment, monitoring, security and every other element of a continuous DevOps life cycle depends on as much of the underlying tasks and actions being automated as possible. Although the provisioning, scaling and decommissioning of most DevOps resources in the cloud are handled by automated processes, inevitably there will be rogue artifacts and other cloud waste left behind.

When we talk about DevOps, we tend to focus on developers, but the reality is that DevOps straddles development, IT operations and general business processes. It is the cross-section of these three areas and how they mesh that enables DevOps to deliver increased agility, scalability and streamlined app development and deployment when implemented effectively.

Managing cloud costs and ensuring efficient use of resources should also be a function of DevOps. DevOps teams tend to hyper-focus on app development, integration, speed of delivery and app performance—all of which obviously are very important. It’s also important, though, to reduce or minimize infrastructure costs and ensure that cloud resources are not being wasted or left behind as remnants that are no longer being used.

Tearing down walls between teams and breaking down silos are hallmarks of DevOps. That same approach should be applied when it comes to managing cost and cloud waste. A white paper from ParkMyCloud notes, “Consider the problem of running resources when they’re not in use and how this contributes to cloud waste. If access is limited and only one person has the ability to turn instances on and off, then one individual is solely responsible for ensuring that cloud resources are used optimally.”

To efficiently manage cloud resources and reduce unnecessary clutter and costs, you need to pay attention to the right data. DevOps relies on monitoring and feedback to ensure apps are running as expected and performance is optimized. That monitoring and feedback also needs to look at things such as whether cloud instances are properly sized, if they’re continuing to run when they’re no longer being actively used, and whether there are rogue or orphaned resources out there that are unnecessary but still being paid for.

Just as automation drives DevOps itself, automation can also be an effective tool for managing and minimizing cloud costs and clutter. According to the ParkMyCloud white paper, 44 percent of cloud workloads are non-production—test, development and QA environments, for example—and don’t need to run 24/7.

“One way to save really significant dollars in dev and test is to switch your resources off when you go home,” suggested Werner Vogels, CTO of Amazon Web Services. An organization can theoretically reduce costs associated with development and test environments by up to 75 percent by simply turning those things off when they’re not needed.

If you think about it, managing cloud costs and clutter in DevOps is essentially the same as managing security within DevOps, which is essentially the same as effectively managing DevOps. You have to consider cloud infrastructure costs as a part of the holistic environment or project; remove silos to empower everyone involved to be part of the solution; monitor key metrics to get useful feedback; and automate the process as much as possible. As with DevSecOps, the main key is to make cloud hygiene and the reduction of cloud clutter an integral part of the DevOps life cycle—not something that is tacked on after the fact.

— Tony Bradley

February 15, 2018
Oracle Unveils Autonomous Cloud Service

Oracle today unfurled at an Oracle CloudWorld event what it describes as a completely autonomous cloud service the company will manage primarily on behalf of application developers.

The Oracle Autonomous Cloud Platform is a managed service that makes extensive use of machine and deep learning algorithms across instances of Oracle software that can invoked on a public cloud or deployed in an on-premises IT environment, said Amit Zavery, executive vice president of product development for Oracle Cloud Platform.

“We’re taking away all the day-to-day management issues,” Zavery said.

The Oracle Autonomous Cloud Platform builds on the Autonomous Database service launched last year. This latest service essentially puts all the responsibility for managing IT operations on Oracle, which is relying on a major investment in machine learning algorithms to automate DevOps processes.

The implications of that capability are profound for IT organizations, many of which Zavery said now will be able to shift more resources over to developing and maintaining applications. At a time when more organizations are focusing on digital business transformation, those organizations need to be able to free up resources to focus in application development, he said.

Amit Zavery, Oracle

Examples of how Oracle envisions the transformation of both DevOps and DevSecOps include chatbots that can be interacted with using natural language processing to automate repetitive tasks to automatically identifying and remediating security issues in code within the context of a continuous integration/continuous development (CI/CD) deployment. There are also controls to prevent data leaks across structured and unstructured data repositories, along with built-in security monitoring tools.

Other capabilities include an ability to create data flows with automated data lake and data prep pipeline creation for ingesting both stream and batch-oriented data, as well as automating the integration of various on-premises and software-as-a-service (SaaS) applications.

Advanced analytics tools span everything from automated data discovery and preparation to visualization tools for displaying trends.

Oracle may have come late to the cloud computing game, but clearly it intends to make up lost ground by infusing higher levels of automation into cloud services that rivals don’t yet provide. Most cloud service providers are headed in the same general direction as Oracle. But the scope of automation being provided by Oracle, spanning both a public cloud and on-premises IT environments, is unprecedented.

In many ways that level of automation may represent an existential threat to a larger number of IT operations professionals. At the same time, it presents an opportunity. IT professionals should be able to spend more time adding true value to the business instead of having all their time and energy consumed by merely keeping the proverbial lights on in the data center.

Of course, it may take a while for most organizations to make a transition to a single stack of integrated hardware and software provided by a single vendor. Most organizations have decades worth of IT infrastructure consisting of databases, middleware, virtual machines, servers and storage systems all from different vendors. Even if organizations decided the time had come to rationalize those investments in favor of a suite of managed cloud services, it would take several years to make that transition.

In addition, many organizations would also still need to evaluate the total cost of acquiring and managing IT infrastructure over several years versus contracting for services over the same period of time.

Regardless of the path a company chooses, IT operations is about to be transformer utterly by artificial intelligence (AI)-infused automaton.

— Mike Vizard

February 12, 2018