devopsy.kinsta.cloud

Tag: cloud services

Bridging the Gaps in SaaS to Meet Business Needs
Today, software as a service (SaaS) is a mainstream model for application consumption, with industry-specific and business process-focused offerings increasingly available. Flexibility, reduced time to market and cost benefits are the top advantages and selling points of SaaS offerings.

SaaS-powered business processes allow businesses to provide feedback in real time, thus enabling a smooth change management process. The agility of such applications also generates higher user-community satisfaction and engagement. As a result, Gartner’s recent forecast predicts the SaaS market size will grow at a compound annual growth rate (CAGR) of 18 percent in the next four years, reaching $127.6 billion USD in 2021.

Despite the apparent benefits, SaaS models carry their own set of disadvantages, especially when the application impacts key underlying business processes. These processes are typically unique to an organization and are seldom available out-of-the-box (OOB). The specific changes an organization needs often proves a solution inadequate and in need of major customization and permissible extensions.

If the design of the solution is stretched too far from the originally intended logic of the software, it can cause major disruptions to future upgrades of the SaaS solution. An alternative to customization is simplifying business processes so they fit into OOB features. However, business users resist adopting a new simplified process, particularly when the process in question is a perceived differentiator. At the same time, it is not in the best interest of vendors to modify their design, catering to the requirements of just a few organizations.

The Crucial Role of Architecture

Business process architecture must be harmonized with solution architecture. That is why architecture plays an essential role in SaaS implementation. Business process architects need to quantify the criticality of business processes and leverage the insights to build consensus among stakeholders, which include business users, SaaS providers and IT departments. The solution architects, on the other hand, should ensure alignment between business process requirements, downstream enhancements to an offering’s capabilities and future readiness of IT to handle upgrades.

Architects now empowered with business process and solution architecture should identify business KPIs that drive SaaS adoption and measure the impact on process performance. Gap and impact analyses tools can be used by architects to identify gaps between business requirements and OOB features of SaaS products. These analyses tools will result in a list of customizations, which need to be further evaluated.

SaaS Evaluation Framework

Each customization made to the SaaS application should be assessed on two dimensions:
1. Potential business impact/criticality: When evaluating the potential business impact, architects should start by identifying sources of differentiation. Differentiation may arise from enhancement in customer-facing capabilities or improvement in operational efficiency—or both. Mapping measurable quantitative outcomes such as CSAT ratings, turnaround time, etc. can help define potential differentiation.
2. Ease and cost of customization: Overall cost of ownership should serve as the primary way to evaluate the ease of customization, and right-size the trade-off between ease of implementing customizations with the ease of maintaining the solution. While the parameters to measure ease and cost of customization need to be defined, considerations include design types, the time and effort required for development, maintenance and upgrading activities (e.g. plug-in/script development).
The above proposed assessment must also identify the following:
1. Impact of not having requested features.
2. Technical challenges in configuring/customizing the solution to meet each requirement.
3. Ability to upgrade SaaS application without having to reapply customizations.
4. List of actions to bridge identified gaps between proposed SaaS solution and existing process requirements.
As displayed in the graphic above, customization needs to be treated differently based on which quadrant it gets mapped to.

Appropriately Prioritizing Customizations

Customizations that are easy to implement but don’t yield any measurable benefit to the business should be avoided as much as possible to eliminate risk, save effort and allow investments elsewhere.

Similarly, customizations that are difficult to implement and carry no clear benefit or impact on outcomes, must be avoided. Instead, IT will have to convince the business to adopt OOB processes.

On the other hand, critical customizations that are easy to implement and maintain should be shortlisted for further steps. Since there is a clear business case warranting customization, architects should ensure that the design approaches are recommended and supported by the vendor.

Must-have business functions requiring difficult customization must be carefully examined. Consider the following questions: Will it still provide perceived time-to-market advantage? Will it increase overall cost of development and ownership? Will it impact scalability, upgradability and integration capability?

In some cases, the SaaS provider may have feature enhancements in its pipeline that would help implement these must-have requirements. If so, the IT team should collaborate with the provider, influencing and defining upcoming product features.

If that’s not an option, an alternative is to implement critical functions outside the SaaS solution and then connecting through well-designed back- and front-end integrations. For example, some SaaS providers allow customers to build composite apps on their platform as a service (PaaS). These apps can provide differentiated features without having to change the core SaaS solution. However, keep in mind that PaaS apps will need real-time integration with SaaS apps to achieve this.

As explained above, not all business processes deem a customization of the SaaS solution. A structured framework should be used to classify which customizations will play a crucial role in any organization’s SaaS adoption journey.

All customizations should be reviewed and approved by the program steering committee consisting of stakeholders from IT, business leadership and the SaaS provider. All parties involved need to have a clear understanding of why the customization is critical—that means business stakeholders need to provide justification for why a workaround or process change is not viable. Similarly, IT and the SaaS vendor need to articulate a plan of action and a road map for upgrades. In doing so, businesses will reap the full benefits of moving toward SaaS.

— Monoj Baruah
September 7, 2018
DevOps 2.0: A New Evolution of Serverless Cloud Architecture
Science teaches us to formulate hypotheses and test them experimentally to advance systematically. While this sounds logical, DevOps—and software architecture in particular—does not follow this approach because current tools make this too cumbersome. So, architecture choices are frequently made by HiPPO (highest paid person’s opinion).

However, the rate of development, especially in the serverless or function-as-a-service (FaaS) space, makes it difficult to gather all necessary information for HiPPO to work effectively. For example, according to AWS, it publishes on average two new cloud services per day, with similar development rates at other public cloud providers. With so many very nuanced choices, picking the optimal architecture without experimentally testing them is impossible.

We propose a fundamentally different approach for developing efficient and robust serverless architectures: hypothesis-driven architecture evolution, which consists of the steps deploy, evolve, measure, evaluate and iterate. In this blog post, we will go through each component and demonstrate how this can be done in an automated fashion to bring out the inner scientists in all of us.

Deploy with Code as Text

To deploy easily and consistently, the serverless architecture stack needs to be fully defined through code/text. This is widely known as infrastructure as code (IaC) and comprises the full infrastructure, from the computational core in the serverless functions all the way to permissions, databases and connecting services. Frameworks such as Serverless Framework and Terraform or vendor-specific tools such as AWS CloudFormation enable this by allowing a single file to define the infrastructure used and to automatically deploy these services. This ensures that multiple versions can be deployed in isolation even though they are hosted to the same availability zone for reducing confounding factors when comparing performance.

Evolve the IaC for Hypothesis-Driven Advancements

This infrastructure file can then be modified and re-deployed to systematically test hypotheses, such as whether an algorithm is faster or a particular autoscaling group is more efficient. This idea was proposed first by James Lewis from ThoughtWorks in the context of general software architecture development, but is particularly applicable for the serverless space.

Measure Performance of the Newly Evolved Architecture

The second key element to this novel way of evolving architecture is the automatic evaluation of any newly deployed architecture without manually recording runtime or specifying interactions between services. Here, tools such as Epsagon can help in automatically detecting the workflows in architectures and analyzing their performance.

Evaluate and Iterate

In this approach, evaluation needs to keep pace with the overall process. To be effective, it is imperative to be able to identify errors and bottlenecks across the entire architecture in a timely fashion. In serverless architectures, most tools focus on the individual function rather than a full transaction from end to end. You may be made aware of a long-running function but you have to scrape logs and go through your code to perform root cause analysis. Tools such as Honycomb or Epsagon help to collide errors across multiple layers or the entire data flow.

Case Study: Improve Runtime Performance of a Bioinformatics Tool

We now describe the two key aspects (deploy and evaluate) on a practical example showcasing how it has helped improve the runtime of a serverless application. We chose the bioinformatics software framework GT-Scan, which is used by Australia’s premier research organization to conduct medical research, to improve its runtime by 85 percent.

GT-Scan was one of the first serverless architectures (Jeff Barr Blog) with a focus on burstable web services that conducts data- and compute-intensive tasks. As such, it relies heavily on all of its components to be as time- and resource-efficient as possible.

We contrast the automated approach against a previous approach in which the performance was evaluated using AWS X-Ray (AWS Public Sector Blog) and summarize our three learning outcomes:

Visualizing the Current Architecture Automatically is Important

Key to rapid architecture evolution visual feedback, especially so if only small changes to the architecture are evaluated. Hence having a visual representation of the architecture helps differentiate deployments and focuses in on differences.

Figure 1: X-Ray view of the functional architecture vs the view of Epsagon’s automatically detected architecture

Use Invocation Count and Runtime to Identify Which Function is the Bottleneck

To identify the bottlenecks in the system, a tabular view over the runtimes of all functions is essential. This also allows us to weed out obsolete or unused functions. A similar analysis can be done for memory use.

We therefore sort by invocation count, which allows us to focus in on the most frequently used methods to target optimization efforts. We can now compare the old and new deployment side by side, by labeling one as “legacy.”

Figure 2: A tabular view of all Lambda functions and their invocation count and runtime

As seen in the functions table, the longest running function and its precursor is from the legacy deployment with its median (p50) duration :
- legacy-sgRnaFunction: 75.7 seconds
- legacy-wuCrisperFunction: 468 ms
- Total: 76 seconds
In contrast, the new tuscanRegressorFunction, which replaces the two legacy-functions, runs in just 1.6 seconds! This is a 97.8 percent reduced running time, which is 47x faster!

Assess Entire Data Flows to Target Top-Down Improvement Efforts

Complex production applications typically contain many managed services and asynchronous events, whose interplay determines the overall performance. In addition to spotting individually slow functions, it is worthwhile to evaluate entire workflows to prioritize optimization efforts to the main data flows.

For each of the GT-scan deployments, the solution identifies two flows: one comprising services watching DynamoDB and the other the API-gateway.

Comparing the two deployments at this level reveals that the main flow in GT-Scan2_legacy takes on average 97.7 seconds before the optimization, while the average runtime for the corresponding data flow in GT-Scan2_prod is 14.1 seconds—a reduction of 85.5 percent—and an overall runtime improvement of 7x!

Figure 3: Comparison between the automatically detected data flows between the prod and legacy deployment.

Visualizing the data flow of the two architectures highlights that our optimization efforts were indeed targeted at the root problem: The legacy deployment uses the two inefficient Lamdba functions, while the production deployment contains only a single more efficient function.

Figure 4: Architecture comparison of the transaction containing the difference between the prod and legacy deployment.

Bringing It All Together

Improving serverless architecture can be done systematically and efficiently by deploying the entire cloud infrastructure stack through code and using an evaluation system to automatically interrogate runtime. Specialized tools such as Epsagon can offer substantial improvements over AWS X-Ray for the evaluation step, by providing a tabular view to easily identify underperforming Lambda functions and offer an interpretable view of the architecture. Detecting data flows in the system helps prioritize optimization efforts to the main transactions of the architecture. Specialized tools help developers save time when documenting performance improvements; using hypothesis-driven evolution principles, we were able to improve the efficiency of GT-scan’s serverless system by 85 percent.

This article was co-authored by the following:

Aidan O’Brien is the main developer on the GT-Scan2 project. He is a Doctoral research student with joint appointment at CSIRO and one of the most impactful CRISPR research facilities in Australia.

Nitzan Shapira is co-founder and the CEO of Epsagon. He is a software engineer, highly experienced in infrastructure technologies and cyber-security.

Shannon Brown is the Senior Director of Growth of Epsagon. She is a software engineer with over 20 years of experience in software development, management, and sales.

— Denis Bauer
July 24, 2018
Survey Finds DevOps Playing Key Role in Cloud Migration

A survey of 450 C-level and VP/director-level technology leaders in the United States, UK and Canada conducted by 451 Research on behalf of Skytap, a cloud service provider, found that lifting and shifting existing applications into the cloud is giving way to either refactoring and rewriting those applications to take advantage of cloud-native technologies.

According to the survey results, 67 percent of respondents plan to migrate or modernize at least half of their on-premises applications in the next 12 to 24 months. The survey found 28 percent of respondents plan to refactor applications using a mix of cloud-native and traditional technologies, while another 20 percent plan to adopt some form of a platform-as-a-service (PaaS) environment. That compares to 20 percent who plan to lift and shift existing applications into the cloud with no changes to the underlying code. Another 20 percent said they will replace existing applications with software-as-a-service (SaaS) applications.

Jay Lyman, an industry analyst for 451 Research, said the survey makes it clear that, when it comes to lifting and shifting applications into the public cloud, too many organizations are still engaged in “wishful thinking.” Most applications migrating to the cloud will need to reworked to one degree or another, Lyman said.

The survey found that only 20 percent of respondents plan to move 75 percent or more of their applications to a cloud platform in the next 12 to 24 months. Just less than half (47 percent) said they would migrate somewhere between 50 percent to 75 percent of their applications.

In terms of methodologies that will be employed to achieve that goal, 54 percent of respondents said they were already relying on DevOps processes, while 46 percent said they are relying on agile methodologies. In terms of talent, 55 percent said they are looking to acquire or retain IT professionals with cloud migration expertise, followed by 52 percent who cited application modernization using cloud services. DevOps skills and multi-cloud operations expertise tied for third at 50 percent.

Just over a third (37 percent) also noted that decisions concerning where best to place a workload were being driven primarily by where an application would run best, while 26 percent said decisions were driven by identifying the best-of-breed cloud-native service. Only 19 percent said their organizations would be employing multiple public cloud service providers. In fact, Lyman noted that while hybrid cloud computing remains the dream state most IT organizations want to achieve, the reality is that most of them will be managing multiple clouds in isolation for many years to come.

More than 80 percent of survey respondents reported managing more than 100 applications, with 74 percent stating at least half of these applications are on-premises. A full 71 percent of respondents said more than half of their on-premises applications are mission-critical. A little over half of the respondents said core business applications including customer relationship management (CRM), enterprise resource planning (ERP), and data analytics were least-suited for hyperscale clouds. According to the survey, the biggest challenge associated with deploying applications in the cloud today remains security (56 percent).

The Skytap survey makes it clear IT organizations are still severely challenged when it comes to migrating applications to the cloud for want of skills. Most applications are not easily migrated, which makes reworking them for deployment in a cloud environment a high priority. In the absence of those skills, however, it’s also apparent that any migration of applications to the cloud is going to occur over an extended amount of time.

— Mike Vizard

July 11, 2018
Evaluating a Multi-Cloud Strategy: The Pros and Cons
First off, let’s define multi-cloud. Clearly, we’re talking about using one or more clouds, but clouds come in different flavors. For example, multi-cloud incorporates the idea of hybrid cloud—a mix of public and private clouds. But multi-cloud can also mean two or more public clouds or two or more private clouds.

So, why is this important? Over the past year or so, I’ve seen a major increase in the amount of companies who use multiple public clouds. In fact, more than 20 percent of ParkMyCloud’s customers use multiple public clouds. With this trend in mind, I think it is time to take a look at the positives of a multi-cloud strategy. But I also want to mention the negatives—because, of course, there’s no “easy button.”

According to the “RightScale 2018 State of the Cloud Report,” more than 80% percent of enterprises have a multi-cloud strategy:

What are the Advantages of Multi-Cloud?

So, why are businesses heading in this direction with their infrastructure? Simple reasons include the following:
- Risk mitigation—create resilient architectures.
- Managing vendor lock-in—get price protection.
- Optimization—place your workloads to optimize for cost and performance.
- Cloud providers’ unique capabilities—take advantage of offerings in AI, IOT, machine learning and more.
When I asked our CTO what he sees as the advantages of a multi-cloud strategy, he highlighted risk management. Our own platform was born in the cloud, so we run on AWS. We also have a multi-region architecture with redundancy (let’s call this “multi-cloud light”) and if we went multi-cloud, we would leverage another public cloud for risk mitigation.

Specifically, he mentioned risk management from the perspective of one vendor having an infrastructure meltdown or attack. AWS had an issue about 15 months ago year when S3 was offline in US-East-1 region for more than five hours, affecting many companies large and small. Software from web apps to smartphones apps were affected (including ours). Certain AWS regions also have been the target of DDoS attacks that have affected service availability.

Having a backup to another cloud service provider (CSP) or private cloud in these cases could have ensured 100 percent uptime. In the case of Alibaba and other cloud vendors, they may have a much stronger presence in certain geographic regions due to a long-term presence. When any vendor gets a toe-hold in a region, its environment has minimal redundancy and safeguards in place that provide the desired high availability; in this case, another provider in the same region may be safer from an availability perspective.

What are the Disadvantages of Multi-Cloud?

Now let’s say you want to go multi-cloud: What does this mean to you? From our own experience integrating with AWS, Azure and Google Cloud, we’ve seen that each cloud has its own set of interfaces and own challenges. It is not a “write once, run everywhere” situation between the vendors, and any cloud or network management utility system must do the work to provide deep integration with each CSP.

Further, the nuances of configuring and managing each CSP require both broad and deep knowledge, and it is rare to find employees with the essential expertise for multiple clouds, so more staff is needed to manage multi-cloud with confidence that it is being done in a way that is both secure and highly available. With everyone trying to play catch-up with AWS—and with AWS itself evolving at a breakneck pace—it is very difficult for an individual or organization to best utilize one CSP, let alone multiple clouds.

A common container environment, for example, can help mitigate these issues somewhat by isolating engineers from the nuances of virtual machine management; however, the issues of network, infrastructure, cost optimization, security and availability remain very CSP-specific.

On paper, there are advantages of having a multi-cloud strategy. In practice—like many things—it’s not as easy as it may seem.

— Jay Chapel
June 26, 2018
What Can the Cloud Do for DevOps?

The cloud has enabled DevOps to grow and expand well beyond traditional boundaries set forth by on-premises production environments. With Amazon Web Services (AWS) and other cloud services providers, DevOps devices are intended to speed advancement by empowering engineers to change, test and push code in a computerized design. This enables organizations to create and send administrations and applications significantly faster than in traditional development environments.

Organizations following DevOps and continuous delivery (CD) practices follow various approaches such as Agile, scrum or even hybrid models to define what is to be built. Whatever your approach, having clarity, context and communication around requirements is critical.

Modern Requirements4TFS, along with TFS/VSTS, make a great platform for requirements management, DevOps and CD.

AWS characterizes DevOps as “the combination of cultural philosophies, practices, and tools that increases an organization’s ability to deliver applications and services at high velocity.” Especially for SaaS programming organizations, DevOps is one of the essential drivers for moving to the cloud in any case. Quickening item advancement can give programming organizations a focused edge with quicker time to showcase for items and highlights.

Integration is the most important part here. DevOps integration is known to target testing, development, maintenance and product delivery for improving security and reliability. Using continuous integration (CI), the developers should acknowledge the business needs and get new productions and applications.

AWS underpins DevOps by giving administrations to manufacture store and send applications and design administration devices. Chef, for example, utilizes Ruby to compose framework design “formulas,” which computerizes the procedure for arranging and working nearby and cloud-based administrations, including AWS.

While DevOps isn’t one of a kind to AWS, AWS has different devices and best practices to make DevOps less demanding and more successful, particularly with regards to mechanization of use advancement and conveyance.

The center best practice is a way to deal with DevOps of “ceaseless incorporation and persistent conveyance” (CI/CD). A CI/CD approach enables you to ceaselessly refresh applications and administrations to present new highlights, settle bugs and react to client needs.

AWS Features

Major AWS features are as follows:

CodeBuild: This tool helps in running the tests and producing software packages which are ready to deploy. It can handle multiple application processes at a time.

CodeDeploy: AWS CodeDeploy can be utilized to computerize code sending to AWS instances to one occurrence or to a large number of examples, and even to nearby servers. This incomprehensibly streamlines application refreshes all through your AWS, eliminating the requirement for a careful manual arrangement.

CodeStar: CodeStar helps in creating new projects with the templates which have selected programming languages that provides AWS services. This also provides identity and access management (IAM) access policies for the secured application environment. For projects using AWS CodeBuild, AWS CodeDeploy, AWS CodePipeline or AWS CodeCommit, this helps in automating the configuration of a continuous delivery pipeline.

The confirmation of-idea process additionally shows you something about your current association, including the current ability and the capacity for the advancement and operational workforce to adjust to new procedures and innovation.

DevOps is by all accounts important to creative associations, as it is a perceived way to convey an incentive to the business quicker, and it’s a situation that can oblige change.

DevOps process requires a solid coordinated effort between developers, operations and managerial staff. That is the reason increasingly DevOps experts are swinging to effectively available cloud-based stages; for example, AWS instead of customary, privately based servers. With AWS, everybody included can access pertinent, institutionalized creation environments, regardless of their specialty or physical location.

What’s more, AWS’ cloud-based framework can be much more financially attractive to organizations than an on-premises infrastructure, as AWS enables clients to rapidly scale processing limit up or down as the necessities dictate. Also, with AWS EC2 depictions, clients can rapidly scale up EC2 occurrences and copy generation situations as required.

It is likewise conceivable to plan EC2 and RDS cases to begin and stop at foreordained circumstances, which guarantee clients aren’t wasting money on unused resources—for example, evenings and weekends. This adaptable, pay-as-you-go approach means AWS clients pay for the servers and capacity they really utilize, which can bring down expenses by as much as 70 percent.

DevOps and AWS have helped IT in various factors to improve in various aspects:

Quality output: Infrastructure as a code has changed the skill set of the team to improve the processes. Code reviews, testing and agility has increased output quality by collaborating and experiencing with the development team.

Process improvement: It’s obvious that combining the two teams can result in an increase in performance. The adaptability and “codification” of the foundation that cloud suppliers such as AWS empowered along with this cross-group joint effort has spurred the desire to do more. Including operations groups in the development procedure and the other way around empowers sharing of understanding and skills.

Bringing out improvements: To provide agile development a quality process, development and delivery tools helps without involving integration in development and delivery. To bring improvements and for bug fixes, teams should work repeatedly, rapidly and reliably at low risk.

Coordinating data management: Data management is combined in the process. Schema management tools actually help with tough tasks such as handling changes in the database schemas code for the requirement of code repositories. This process decreases the risk by rolling the database front and back and being controlled and repeatable.

Security: Security is an important area that needs to have a more pronounced role in DevOps. Every code is stored in AWS CodeCommit, so any change in the code can be known and the security can be built.

Conclusion

The flexibility provided by the cloud and AWS provides the platform for a cultural shift that has brought benefits to both operations and development teams.

— K Maneesha

June 19, 2018
Oracle Advances AI Effort to Automate DevOps

Oracle today announced the general availability of an expanded Oracle Cloud Platform service that promises to automate most back-end DevOps processes by relying on a combination of machine learning algorithms and other forms of artificial intelligence (AI).

The Oracle platform-as-a-service (PaaS) environment has also been expanded to include Oracle Mobile Cloud Enterprise, Oracle Data Integration Platform Cloud and Oracle API Platform Cloud alongside existing continuous integration and continuous deployment (CI/CD) cloud service. Oracle also revealed today that later this year it will also add blockchain, security and management and support for additional database workloads, including OLTP and NoSQL, that expand on existing Oracle Database, Oracle Autonomous Data Warehouse Cloud, Oracle Analytics Cloud, Oracle Integration Cloud and Oracle Visual Builder services.

Siddhartha Agarwal, vice president of product management and strategy at Oracle, said via the cloud service, Oracle plans to automate DevOps processes to the point where organizations will be able to allocate most of their time and effort to building applications. Today, developers are spending as much as 50 percent to 60 percent of their time on DevOps processes rather than writing application code, he said, and the Oracle Cloud platform automates a broad range of operational functions including tuning, patching, backups and upgrades.

Oracle Cloud Platform is designed to be an infinitely elastic autonomous cloud service that can both anticipate application requirements and dynamically adjust to changing workload conditions. Over time, the platform also will be able to increasingly provide recommendations based on the characteristics of the application workloads being built and deployed, Agarwal said.

The Oracle API Platform Cloud service, for example, already continuously learns about usage patterns to recommend allocation limits, configurations and policies using predictive algorithms, he said.

Meanwhile, the Oracle Cloud Mobile Enterprise service provides access to machine learning algorithms that make it much easier to incorporate chatbots into mobile applications, Agarwal said. Machine learning algorithms are now also relied on to create Big Data lakes and the data pipelines needed to make that data available to application developers.

Those services are all extensions of an Oracle Developer Cloud service for building applications that supports build frameworks such as Maven, Ant, Gradle, npm, Grunt, Gulp and Bower, as well as command line interfaces for Docker, Kubernetes and Terraform. Frameworks such as JUnit and Selenium for both logic and UI testing are also included.

Agarwal said one of the primary reasons DevOps process have not been as widely adopted across the enterprise is that it’s simply too complicated for most IT organizations to set up and then continuously manage all the underlying infrastructure required. By moving more of the responsibility for the operations side of the DevOps equation on to an autonomous cloud service managed by Oracle, he said, it becomes simpler for enterprise IT organizations to focus their energy on application development processes.

It may take some time for enterprise IT organizations to get comfortable with ceding that level of control to a cloud service provider. But whatever DevOps path they choose, it’s apparent that machine learning algorithms coupled with other AI advances are about to automate broad swaths of the DevOps universe.

— Mike Vizard

June 13, 2018
Rackspace Aims to Push VMware Everywhere

Rackspace is expanding its efforts to provide managed services for private clouds based on VMware that can now be deployed anywhere.

Peter FitzGibbon, vice president and general manager of VMware at Rackspace, said Rackspace Private Cloud Everywhere, powered by VMware, is making an effort to provide infrastructure services that enable IT organizations to devote more resources to building applications. As part of the effort, Rackspace is making the managed services it provides a natural extension of an organization’s DevOps processes.

Previously, Rackspace provided support for VMware in data centers it owns. Now Rackspace will manage instances of VMware deployed anywhere, including public clouds such as Amazon Web Services (AWS), FitzGibbon said.

FitzGibbon noted Rackspace already has more than 70,000 VMware virtual machines under management—a number the company expects to expand significantly as more instances of VMware are deployed on the cloud in addition to on-premises IT environments.

Longer term, FitzGibbon said IT organizations should also expect to see Rackspace extend the reach of the managed services it provides for VMware to include storage and network virtualization, as well as Pivotal Container Service, an instance of a container platform developed jointly by Pivotal and its sister company VMware.

FitzGibbon said most organizations are on a multiyear journey when it comes to making the transition to the cloud. Most are still analyzing which classes of workloads make the most sense to deploy on a public cloud. Also slowing that transition are new data sovereignty requirements that force organizations to rethink where data is hosted around the world, he said.

As they make that transition, many of those organizations are concluding they don’t want to manage the underlying infrastructure that is now distributed across multiple data centers. Instead, they want to reallocate their own limited resources to developing software faster, FitzGibbon said.

FitzGibbon also noted that taking advantage of advanced cloud capabilities such as cloud bursting or moving workloads back and forth between environments requires a level of expertise many organizations don’t have in place today.

As more organizations realize they need to become software companies to remain competitive, many are rethinking how IT infrastructure is managed within the context of a integrated DevOps processes. As part of that transition, many are starting to evaluate how much of the management of IT infrastructure they can outsource within the context of those DevOps processes. Rackspace is essentially making the case for retraining the existing IT staff focused on IT infrastructure to focus more on managing applications rather than physical and virtual infrastructure.

Naturally, that level of cultural IT transformation inside any organization will take time to achieve. Not every organization is comfortable giving up control over its IT infrastructure. Others will prefer to collaboratively manage IT infrastructure with a service provider. Just as significantly, not every member of the IT staff managing infrastructure wants to be retrained.

Nevertheless, as the sheer volume of IT infrastructure that needs to be managed becomes more distributed, it’s unlikely most IT organizations will be able to manage all those systems on their own.

— Mike Vizard

May 4, 2018
DevOps’ Contribution to UK’s Digital Sector

The UK’s G-Cloud is a national initiative that helps the public sector find and use cloud-based services. This is basically a DevOps initiative that combines cultural tools, practices and philosophies to help increase the ability of an organization to provide services and applications at high speeds, which helps them provide better services to their customers. Its high-security protocols, improved collaboration, reliability, rapid delivery and high speeds makes it better than traditional management processes.

This technology seeks to breach the gap between private companies and the public sector—in particular, the government—by offering a wide range of digital services. So far, the adoption of DevOps in the UK’s public sector has benefited the UK’s digital sector in numerous ways—for instance, DevOps has enabled the government of the UK to ensure the digital-first experience for the public.

DevOps enables marketers to establish clear marketing-related analytics. Using its cloud-based technology, marketers get a chance to influence how they can use available data in decision-making and be competitive. Besides, its interdepartmental communication platform offers a solution to companies to change how they operate to meet customer needs. This can easily be done by integrating customer feedback in quality improvement. The use of DevOps in making IT infrastructure, application operations and application development work as one reduced failure rates by more than 50 percent, reduced time to market by 50 percent to 75 percent and increased capacity creation by 25 percent to 30 percent.

In the engineering digital sector, DevOps has played a crucial role in changing the focus of from software development life cycles (SDLCs) and software to engineering and services. The adoption of DevOps in different sectors—particularly engineering and governments—has shaped its demand and supply over the last decade.

Before the invention of DevOps as a cloud service, the government was not digitally structured to handle the demands of the population of today. DevOps bridges the gap and offer digital-first services to the public. Since its implementation, DevOps has made operations that were once a dream become a reality for the public. The most benefiting organizations are public organizations; they procure digital cloud services, then move on to use the services to enhance the provision of services to the public through a faster delivery framework that enhances the competitive advantage of the involved organizations.

The growing use of digital technology in the UK has led to an astronomic type of transformation that is bound to positively affect the infrastructure of the nation moving forward. It is undeniable that more companies using DevOps is spurring a revolution of digital transformation that is bound to change the way services are provided to the public. The public sector in the UK has now a more valuable competitive advantage in that it is able to provide its services in a digital-first kind of experience. DevOps has therefore not only made services available to the digital population of the UK but has enabled access to every single individual in the nation.

Conclusion

The transformation brought about by DevOps will also increase the quality of services by ensuring the continuation of cloud services that provide faster service delivered. However, one unique aspect of the digital transformation related to the adoption of DevOps is that the rate at which IT skills will grow in the public sector will be faster than previously experienced in the public sector. This is bound to be the inevitable future of the use of DevOps in the digital sector. The growth of IT skills to match the use of the advanced technology will enable better use of the cloud services, creating the potential for continued growth in the future.

— Subramonian

May 4, 2018
VMware Extends vSphere Hybrid Cloud Reach

VMware this week extended its campaign to automate IT environments based on its hypervisors by adding a link capability that enables the VMware vCenter platform to manage instances of VMware vSphere running on-premises and in public clouds such as Amazon Web Services (AWS) and IBM Cloud from the same console.

Mike Adams, senior director of cloud platform product marketing for VMware, said the linking capability added to VMware vSphere will enable DevOps teams to deploy the VMware hypervisor anywhere without having to invest in a separate management framework for each environment.

At the same time, VMware is also updating VMware vSAN storage software that, among other capabilities, adds a self-healing feature designed to minimize disruptions in the event of underlying hardware failure.

Version 6.7 of VMware vSphere and VMware vSAN also now support enhanced client software based on an HTML5 interface that can manage VMware NSX network virtualization software, vSAN and vSphere along with additional third-party products.

Other new features in VMware vSphere include ESXi Single Reboot, which reduces patch and upgrade times by halving the number of reboots required to one, and vSphere Quick Boot, which will skip hardware initialization steps to gain further re-start efficiencies.

VMware is also adding support for persistent memory to speed vSphere performance and adding support for graphics processor units (GPUs).

There’s also now support for both Trusted Platform Module (TPM) 2.0 Support and Virtual TPM 2.0, which serves to protect virtual machines and hosts from being tampered or compromised by the loading of unauthorized components or allowing a guest operating system running on the hypervisor to circumvent existing security controls.

Finally, VMware is making available an instance of VMware vCenter management software running on a dedicated appliance.

Adams said VMware today has 500,000 customers running VMware vSphere, compared to 10,000 that have elected to also run VMware vSAN storage software. The goal for the company is to enable more IT organizations to embrace hyperconverged infrastructure by moving storage software on to the same server where VMware vSphere runs. That approach dramatically reduces the total cost of operations for most organizations, he said.

As VMware makes an arguably belated push into the public cloud, the unit of Dell Technologies is counting on a massive installed base of on-premises customers to move and expand their existing investments in VMware vSphere on public clouds. While there’s no doubt that approach will appeal to significant part of the VMware installed base, many customers have already invested in the hypervisor platforms used by AWS, IBM and Microsoft.

When it comes to lifting and shifting an existing legacy applications into the public cloud, VMware clearly has the inside track. But when it comes to development of greenfield cloud-native applications, VMware vSphere is not often the first choice of application developers, many of which view VMware vSphere as part of an inflexible on-premises legacy IT environment that they deliberately left behind.

To its credit, however, VMware is making significant strides in embracing advanced automation technologies that one day soon might put those developer concerns to rest once and for all.

— Mike Vizard

April 18, 2018
IBM Unfurls Cloud Platform for Building Microservices

IBM has unveiled a new development environment in the cloud designed to make it easier to build microservices.

John Duimovich, IBM CTO for Java, said Microclimate provides a complete framework building applications based on microservices written in Java, Node.js or Swift.

Microclimate runs on an instance of IBM Cloud Private, a private cloud based on Docker containers that is hosted on the IBM public cloud. Once those applications are developed, organizations can either deploy them on-premises or in a public cloud of their choice.

Microclimate makes use of Kubernetes and Docker containers to create and orchestrate the microservices development process, which can quickly become a complex endeavor. Because of the issue, Duimovich said, more organizations will be pushing development of microservices into cloud computing environments that provide access to what amounts to a turnkey application development pipeline.

Duimovich noted it’s possible to more closely mirror the production environment an application will be deployed on using compute resources that can be invoked on demand. Instead of developing an application on a laptop, developers can stress test microservices in the cloud by, for example, engage in “chaos monkey” testing, wherein developers allow a microservice to fail to see how the overall application reroutes requests to other microservices, said Duimovich.

Developers also can engage in A/B testing in a way that would not be economically feasible to engage in when applications are developed on-premises simply because of the amount of additional IT infrastructure that would have to acquired and provisioned, said Duimovich.

The cloud also makes it easier for teams of developers to collaborate on the development of microservices-based applications regardless of geographic location, Duimovich added. Developers may still choose to write code on their local PC, but when it comes time to load it into an application, the Microclimate platform makes it easier for everyone on the team to observe how that microservice behaves within the context of a larger application.

IBM will also make available diagnostics tools to enable developers to more easily discover why their applications might be behaving in a certain way.

While not every application may lend itself to being constructed using microservices, many organizations are now concluding they are simply a better way to develop reliable software. In addition, developers can be given ownership of specific sets of microservices end to end, which not only gives them more control but also makes them accountable for their overall quality. Of course, building applications made up of hundreds of microservices is going to require organization to implement DevOps best practices, which Duimovich said IBM is more than willing to share with customers.

No one knows for sure when most applications running in a production environment will be made mainly of microservices. But given the rate at which they are now being used to develop applications, it’s now only a matter of time before such applications become dominant.

— Mike Vizard

March 30, 2018