devopsy.kinsta.cloud

Author: Twain Taylor

How Organizations Benefit from AWS App Patterns

As a startup, an organization thrives by breaking rules, challenging the status quo and standing for all that is against the norm. The same rules don’t apply once the same organization grows, matures, becomes popular, gains a long list of clients and expands to a global footprint. With scale and growth comes the need for reliability, consistency, being able to deliver the same level of service to all customers and keeping promises made to customers. At this stage, application patterns become indispensable to an organization’s day-to-day functioning.

Support of the Application Now and Long-Term

Mid- to large-size organizations typically deal with numerous internal-only applications and external vendor applications. These applications are changed and updated regularly. To support the applications’ needs, and effectively manage them, organizations need a change management system in place.

A service such as AWS Config helps to audit AWS services that power applications so there’s increased visibility. It tracks changes made by users and applications, and presents a clear picture of how these changes impact AWS resources.

Enabling Shift-Left Without Additional Overhead

DevOps bring together Dev, QA and Ops into smaller, cross-functional teams. The goal is to break down silos between teams, facilitate collaboration and drive better results faster. Accordingly, shift-left is a tactic used to encourage QA and Ops teams to play a more pivotal role in the initial Dev stages of the pipeline.

The benefits are many. QA brings their experience of testing the application to its limits and informs about what’s feasible to implement. Ops chimes in with concerns and things to watch for once deployed. While shift-left is great from a team standpoint, it can meet with hurdles and can fail if communication patterns are random, and ownership of each step is not clearly defined.

Application patterns encourage systematizing this collaboration between teams. Patterns help to define the type of infrastructure to be used, their configuration and the kind of tools that fit in with the team’s requirements. Application patterns guide decisions and help to make the right choices, and sometimes compromises, at every step.

Supporting the Advancements in Open-Source Without Fear of Tool Attrition

There is an explosion of open source tools today. If DevOps teams are attracted to the next shiny new open source tool, they’ll soon find themselves overwhelmed with tools they don’t use and that slow them down.

Open source tools evolve quickly, and their popularity rises and falls with the times. One look at the open source monitoring space will show you that older tools such as Nagios and Zabbix are now becoming less relevant, and modern container-aware monitoring tools such as Prometheus are taking their place.

AWS supports the use of the top open source tools; for example, Elasticsearch. The AWS Elasticsearch service integrates seamlessly with Kibana for visualization and delivers the ELK stack without the maintenance.

Application patterns enable you to define a strategy for tool adoption. You may find the best open source tool in the world, but what’s the point if you can’t use it in your toolchain, or if it slows down the pace of operations? The popular DevOps mantra of people, processes and then tools holds true here.

Value Stream Management

Value stream mapping is about visualizing the flow of value from an organization to its customers. In simple words, it’s about taking stock of what you have to offer to customers and monitoring how your offerings change over time.

Value flows outward to customers, as well as internally between employees and systems. For example, in the context of DevOps, it helps to map the value of Ops to Dev and QA. As these teams are each other’s internal customers, knowing what the value stream is can help remove bottlenecks and drive greater efficiency.

Building a Team and Culture First

AWS is a great place to build team culture as it is expansive and includes services for pretty much anything you’ll ever need. You can find tools such as CodePipeline to quicken development pipelines, to make sure everyone on the team is informed of important changes using CloudWatch and SNS queues, and to automate common tasks with Lambda.

Rather than jumping feet first into AWS and then figuring out how it all works, it pays to first define application patterns and team culture that will govern the way you use AWS. Patterns and culture are closely related. If culture is about the people, application patterns are about the infrastructure and technology stack being used by people.

Conclusion

Whether you’re yet to move to AWS or are already on board but not getting the most out of it, application patterns help evolve the way you manage applications in AWS. Application patterns help scale applications over the long term, they enable shift-left for DevOps teams without the friction of overhead. Application patterns make it possible to adopt the right open source tools and find success with them. By using application patterns you can visualize the entire process and drive great efficiency, and finally, they support great team culture within DevOps teams.

DevOps teams that run their operations predominantly on AWS need not fly blind. Application patterns bring greater visibility, control, collaboration and ultimately value.

This sponsored article was written on behalf of Eplexity.

— Twain Taylor

November 12, 2019
What Are AWS Application Patterns?

The cloud-native approach is not just about compute power and cloud services. A “set it and forget it” attitude won’t work with cloud native; there are far too many moving pieces and there is just way too much complexity. Instead, this approach requires constant testing, optimization and improvement. This is epitomized in the two key phrases of the DevOps methodology: continuous integration and continuous delivery.

To make this a reality, however, it takes a strategic approach to defining application patterns that will govern the way in which cloud-native applications are built and shipped, rather than a one-off effort. Since AWS is the leading cloud provider, we should discuss which application patterns are relevant to the AWS platform. There are many aspects to consider when it comes to AWS application patterns, and we will cover them here.

Operational Excellence

The best starting point for application patterns is a commitment to operational excellence. Typically, the term “Ops” is used to identify the IT team, but in this case, operational excellence rests on the shoulders of Dev, QA and Ops teams. In cross-functional DevOps teams, every member should strive for operational excellence at every step–even in the smallest of tasks.

In their white paper on operational excellence, AWS encourages its users to manage operations as code. This helps avoid human error, enables automation of complex processes and allows for quick and easy rollback when errors occur. Failure, according to AWS, is an opportunity for learning. They even advise performing “pre-mortems” that try to anticipate potential points of failure before a deployment.

AWS Trusted Advisor is a useful tool that enables this type of accountability and shared responsibility within a team. It checks and reviews your new and existing AWS workloads looking for opportunities to save costs, improve performance, tighten security or follow best practices for scaling operations.

Security

Security is a pattern that is non-negotiable. The term “DevOps” has inspired another variation called DevSecOps that signifies this fact. Security operations take center stage when talking about DevOps.

The interesting thing about DevSecOps is it actually results in more freedom, flexibility and trust across teams when done right. This is unlike traditional approaches to security which created silos, stifled creativity and slowed down innovation. Security is now a key piece of the puzzle, not an afterthought. AWS has many machine learning-based security solutions such as Macie which automatically identifies and secures personally identifiable information (PII).

Along with this, configuring role-based access controls using AWS IAM is essential to have greater control over who or which applications access data and for how long. Access Control Lists govern access to data stored in AWS S3 buckets.

The news is full of instances of data breaches due to weak security policies and access controls. Capital One is a recent example of a data breach that affected 100 million of its users. While security in the cloud is more complex than before, AWS has the necessary tools and systems in place. It’s up to organizations to implement a security strategy that prevents misuse of their data.

Reliability

Today, there is a low tolerance for downtime because of the potential loss of revenue. With the stakes so high, reliability is a pattern any application custodian would have high on their list of priorities. AWS has multiple reporting and health monitoring tools to keep you constantly on the pulse of your applications.

Architectural patterns like microservices enable better resilience by decomposing monolithic applications into more manageable chunks called services. This “divide and conquer” approach leads to higher availability, which is critical for SaaS applications.

Patterns like chaos engineering seek to intentionally kill random instances and services and force the DevOps team to figure out workarounds and backups for every scenario.

Application Performance

With the explosion of data, applications are always dealing with lots of data to transfer, store and process. An application’s performance depends on three factors: the backend data storage layer, the middleware components and the frontend.

The backend data layer is the most critical component when it comes to performance. Choosing the right storage formats, database types, storage devices and organization patterns all contribute to the speed of data access. AWS has an amazing array of storage services, including S3, RedShift, Aurora and Glacier. AWS gives its users every type of storage solution, all of which should be considered to improve data management.

AWS is devising new ways to query large datasets without bearing the load on your existing systems. RedShift Spectrum is one example of this. It is a great way to “minimize the need to scale Redshift with a new node, which can be expensive.” If you’d still rather not have to manage any RedShift clusters on your own AWS Athena is a great serverless alternative

That gives you all the power you need to query large datasets in S3 without having to maintain any clusters of your own.

This pay-per-use model is making its ways across the entire AWS stack with services such as ECS and Fargate offering completely serverless experiences when operating containers at scale. What started out with AWS Lambda is catching on fast, and many AWS services like the ones mentioned above enable serverless experiences with a focus on application performance.

Cost Optimization

When moving to the cloud, pricing is completely different. Rather than paying for perpetual licenses, you now pay a small fee for every small resource that you use. Though small on its own, you’ll soon realize that cloud costs can shoot up easily if you’re not paying close attention to your spending.

Cost optimization is necessary as you scale operations in the cloud. Cost optimization includes looking for more efficient services, whether that’s within the same vendor platform or a different platform. At a minimum it may require a lift-and-shift approach to transition from expensive old infrastructure to inexpensive new alternatives. For example, shifting workloads from VMs to containers to serverless within the same platform can show great cost savings, since containers and serverless are generally more cost-effective than VMs.

It pays to leverage the expertise of experts in this area. They should ideally be people who have spent years using AWS, understand Well-Architected best practices and have found ways to cut costs and derive more value from the same budget.

Application Patterns Enable Extensibility

Microservice applications adopt a pluggable architecture. This enables them to be easily integrated with external applications. Typically, API-based communication patterns are most common. AWS API Gateway is a service that manages API design for AWS applications. In some cases, an SDK is the better choice–for example, when you need more control over the developer experience and integrations. It’s important to know when to choose either option.

Application Patterns Enable Portability

Portability is the ability to move workloads across instances without interrupting their functioning. As instances change, the workloads which they support shouldn’t be affected. This is only possible if there is a clear separation layer between the workloads and the infrastructure that runs them.

Application Patterns Enable Shift-Left

The DevOps methodology is known to encourage a shift-left approach to software delivery. This means that not only Dev, but also QA and Ops contribute to the design and development stage of an application. This fosters deeper collaboration across teams and breaks down silos.

A shift-right approach holds true as well. Shift-right means developers are responsible for the code they write. They are equal owners with operations teams for the resilience of the apps they build and also the bugs they introduce into the system. This practice of putting ownership and responsibility where it belongs is very healthy for a DevOps team.

AWS facilitates pipeline management using tools such as CodePipeline, CodeCommit and CodeDeploy. They each perform similar but complementary roles and help build a CI/CD pipeline. They make it easy to get started with CI/CD within the AWS platform.

For organizations further down the line in their cloud journey, AWS’ pipeline management tools may seem too simplistic for something like GitOps. Instead, they’d want to look outside AWS for tools such as Jenkins X or Weave Flux which are designed with GitOps automation in mind. Whether it’s the simple or advanced route, a pipeline brings great benefits over a manual development process.

Conclusion

Though tools enable the implementation of helpful application patterns, on their own, they are ineffective. Application patterns need a deliberate strategy and an approach for a start. Only after a strategy is in place, can you move to deciding which tools to use. With a strong strategy in place, any of the tools mentioned here can be swapped out for other better tools and the results will be the same. It’s important to not be distracted by the next shiny tool but keep a keen focus on the strategy for implementing AWS application patterns.

As we’ve seen here, application patterns are diverse, but they all build upon each other. Without even one of these pillars, organizations would not be able to realize the goal of cloud-native applications. On the other hand, if they give careful thought to each of these application patterns, organizations would deliver cutting-edge applications that can only get better with the passing of time.

This sponsored article was written on behalf of Eplexity.

— Twain Taylor

November 7, 2019
Achieving Open and Integrated Development with IBM Z

“DevOps” and “mainframe” are not words you often hear in the same sentence. Yet, the reality is that even in our current age of DevOps, mainframes remain the mainstays of many companies’ IT infrastructure.

That’s why it’s critical for organizations to find ways to bring mainframe software delivery up to speed with modern DevOps practices, which emphasize collaboration, agility and continuous deployment of software to meet quality and time-to-market pressures. It’s also essential to be able to de-silo software delivery teams with a unified pipeline that includes common, modern source code management (SCM) and other tooling.

This is one area where the IBM Z Open Development environment can deliver real value. Built with the goal of supporting modern source code managers such as Git, IBM Z Open Development helps make a common DevOps pipeline, including mainframe teams, more practical through use of modern, open SCM, plus other essential features for developers.

Keep reading for details on how Z Open Development works and what it can do to make mainframes DevOps-friendly.

IBM Z Open Development: Making Developers’ Lives Easier

There is a looming shortage of mainframe developers as the current experts retire; according to BMC’s 2018 mainframe survey, staffing and skills shortage is the second top concern for the mainframe ecosystem. This is not an ideal situation for organizations that rely heavily on mainframes. To solve it, organizations must allow all developers to work on mainframe software, instead of relying on mainframe specialists.

With Z Open Development, developers are armed with the capabilities they need to integrate mainframe work with a common DevOps pipeline that employs a modern, shared SCM. They also have the ability to perform program analysis, edit, build and debug in a way that is similar to other development platforms.

Git is the de facto SCM for the open source community, and enterprises are also embracing Git as the standard SCM for distributed software delivery. Z Open Development makes key Git features such as full Isolation and true parallel development, a reality for mainframe development teams.

Traditional mainframe library managers don’t offer these features; hence, they don’t overcome the isolation that separates mainframe development from development for other platforms. Z Open Development tackles this problem by offering IBM Dependency Based Build and provides enterprises a standardized implementation of Git.

Essentially, Z Open Development is purpose-built IDE for developing and maintaining z/OS application components with a modern SCM that supports parallel development. It provides integrated development and build automation, which can be joined with a common DevOps pipeline. This provides a path to migrate traditional mainframe library managers to modern source code management systems such as Git and Rational Team Concert.

Key Features

Z Open Development is a neat and lean offering that can help development teams transform their software delivery around a common, automated delivery pipeline. Z developers can join a platform-neutral, continuous integration and deployment pipeline that is inclusive of z/OS. However, Z Open Development offers other attractive features that developers require:

1. Dependency-Based Build

IBM’s Dependency Based Build (DBB) allows clients to set up the build for COBOL, PL/I and other traditional z/OS languages just as they would other distributed languages through the use of modern scripting languages. By following the same model as distributed languages, and using standard scripting languages such as Groovy, the z/OS build can be easily added to the same CI/CD pipeline and managed by the same skills building the pipeline today. This ability to use the same CI/CD pipeline coordinator (such as Jenkins) removes the separation and allows for the creation of one coordinated pipeline. This includes being able to standardize on the approval flows, using the same quality gates and supporting the integration of the multiple parts of the application together.

DBB extends the Groovy language with an additional set of java APIs to allow access to run MVS, TSO and ISPF commands, as well as a facility to run existing JCL. DBB also provides a set of open source samples including a configuration-based build that can be used within your own organization, with minimal modifications.

With its GroovyZ capability, DBB also supports the ability to do automation in the pipeline for any additional configuration required. Since it’s Groovy, existing automation created for other platforms can easily be reused for z/OS.

2. Modern Editors

Developers can use modern editors for COBOL, JCL and PL/I to develop their applications. These editors are familiar and provide syntax highlighting and source code assistance to make coding a breeze.

3. Visual Program Analysis

Developers can check out the graphical views of the logical flow of any program they are working on for better program understanding. Developers can also access the graphical view of data flow within their program to identify different data elements and understand how they are populated and modified.

4. IBM z/OS Debugger

Z Open Development comes with the powerful Eclipse-based, source-level IBM z/OS debugger, which can be used to debug 24 and 31-bit z/OS applications written in COBOL and PL/I. Developers can modify variables during debugging while also being able to insert breakpoints during or prior to debugging. The visual debug capability provides developers with a graphical view of the execution flow through their program.

5. Simplified Integration

DBB integration with the editor enables developers to compile the programs using the same scripts defined for the pipeline build, which includes copying files with any dependencies to a specified host, running a build process and returning errors.

If the shared, modern SCM for the DevOps pipeline is Rational Team Concert (RTC), Z Open Development also offers RTC integration.

6. The Foundation for Z Open Unit Test

In addition to all of the above, Z Open Development lays the foundation for Z Open Unit Test, a unit testing tool for z/OS applications built on the Z Unit capability. Thus, Z Open Development allows developers to streamline and automate not just their SCM process, but also unit testing. Note that the Z Unit capability is also offered in IBM Developer for z Systems.

Empowering the Endangered

DevOps is based on the idea of eliminating silos to have a more collaborative approach to application development for more efficient and predictable output.

Mainframes have long been isolated, which places them in opposition to the fundamentals of DevOps. Z Open Development arms developers with the capabilities they need to build and maintain mission-critical software while still leveraging a shared DevOps pipeline that includes Git and Jenkins. It offers an easy first step to DevOps adoption and equips DevOps teams with the power to develop mainframe applications with familiar, shared skills and tools.

— Twain Taylor

August 23, 2019
Going Cloud-Native with IBM Z as a Hybrid Cloud Platform

When people use the phrase “they don’t make ‘em like that anymore,” 100-year-old bridges, Jon Snow’s sword and American muscle cars often come to mind. If the topic of discussion happens to be computer technology, however, mainframes are without a doubt the Valyrian steel of the enterprise and lucky for us, are still in production today. While the cloud computing concept as we know it has been around for only about a decade, mainframes have been delivering on-demand access to compute and storage resources that are safe, scalable, highly available and resilient for half a century.

Big Iron Advantage

In today’s enterprise scenario, the mission to gain an edge over the competition in terms of pure horsepower can be elusive, to say the least. Although 20% of the easy enterprise workloads have moved to cloud platforms, it is estimated a large amount of data and applications continue to be run on-premise as enterprises determine their hybrid cloud strategy. Far from being irrelevant, mainframe architecture now finds itself at the center of this digital battle, causing disruption and giving its users a much-coveted and undeniable edge over the competition. In addition to running over 8,000 VMs on a single system, mainframes offer some of the most scalable storage in the industry.

In case that isn’t enough, couple that with pervasive encryption, multi-factor authentication, a co-processor dedicated to cryptography and the most trusted and secure Linux environment in the industry today. What you get in the end is a major breakthrough with regard to cloud limitations that many early adopters of cloud technology found out about the hard way. These limitations are especially true with regard to cybersecurity, and though private clouds help alleviate these risks to an extent, IBM Z removes these risks by enabling all-encompassing encryption.

Enabling the Hybrid Cloud

While most people were skeptical of mainframes making a comeback until about a year ago, the majority seem to have changed their tune. There are two reasons for this: One is IBM’s new take on the mainframe, called IBM Z; and the other reason is its applications with regard to the hybrid cloud. Hybrid basically refers to organizations using a broad combination of public, private, IaaS and Paas in the same application solution. Mainframes are proving an important part of hybrid infrastructure thanks to the massive compute, storage and scalability features they can deliver.

Another advantage mainframes have in a hybrid environment is simplicity. Every engineer knows the more moving parts, the higher the risk of a breakdown, and the same holds true for the hybrid cloud. In a complex, multi-cloud environment that often spans more than one public cloud and a variety of on-prem resources, the more discrete devices involved in a network, the higher the risk of something failing. With a mainframe like the IBM Z, you have one device that delivers broad functionality at high efficiency and low cost. And it does it for a few decades, without complaining.

IBM Z and the Cloud

IBM’s Z models are lean, mean, transacting machines. Recent innovations in hardware and software design have made it possible to run not just native mainframe apps, but also most Linux-based operating systems and applications on these systems. IBM Z also features machine learning and AI frameworks, as well as support for Apache SparkML, TensorFlow and languages such as Scala and Python. Capable of running more than 12 billion fully encrypted transactions per day on a single machine and 850 million on IBM’s skinny version, the z14 has a 35% capacity increase for workloads compared to the z13, and it’s being touted as the most powerful transaction machine in existence today.

Combining mainframes and cloud platforms in today’s hybrid environments may sound like old wine in a new bottle, but it effectively gives you the best of both worlds–the scalability of the cloud, along with the power, security and dependability of the mainframe. Additionally, the mainframe’s ability to house both data and applications on the same device, while dedicating processors to specific operations independently, make it ideal for ensuring speed in such complex and distributed environments. IBM Z also features a multiple processing structure that makes it ideal for dealing with the varying bandwidth needs of modern applications. It can process Java workloads up to 50% faster than x86 servers.

Cost Efficiency

Forty-four of the top 50 banks in the world run on IBM Z servers right now. They understand that running their applications on a mainframe provides security and scalability for a compelling return on investment. Large enterprise systems have had a perception of being expensive, but when you factor in such things as space, power and cooling efficiency, as well as the number of personnel required to administer the system, the total cost of ownership is a value-add when leveraging Z in your hybrid cloud strategy.

— Twain Taylor

August 22, 2019
3 Examples of AI at Work in DataOps

Artificial intelligence (AI) is making all the difference between innovators and laggards in the global marketplace. Yet, implementing a state-of-the-art DataOps operation involves a long-term commitment to putting in place the right people, processes and tools that will deliver results.

In this post, we look at three organizations that are doing cutting-edge work in the field of DataOps. We look at the specific strategies they use and the results they’ve seen as they navigate the uncharted waters of DataOps.

Uber: End-to-End DataOps

Uber is very vocal about the way it leverages AI across its apps and services globally. The company runs all its machine learning (ML) models on a platform called Michelangelo and use many other proprietary tools such as Manifold, Horovod and Piper to optimize and scale these operations.

Michelangelo helps manage DataOps in a way similar to DevOps by encouraging iterative development of models and democratizing the access to data and tools across teams. On top of this platform, Uber uses other tools to help data teams.

Uber ran its models in Tensorflow and realized model training was taking too long because of the large data sets it was dealing with. Taking a page from Facebook’s data team, the company realized the power of distributed training. This would enable Uber to run data operations in parallel on hundreds of distributed GPUs, rather than on a few GPUs. Yet, managing all this would be a challenge, which is why Uber built a tool called Horovod. Now under the auspices of The Linux Foundation’s Deep Learning community, Horovod supports additional frameworks such as PySpark, Petastorm and Apache MXNet. Additionally, using mixed precision training, Horovod is able to optimize the use of memory when running models, and in doing so, it enables running larger data models or running numerous mini-batches of data in parallel.

Manifold is a visualization tool that helps to gauge the performance of various models against each other. Rather than use a simplistic, two-dimensional axis to plot performance data, Manifold groups large quantities of model performance data into subsets that avoid duplicating the important indicators of performance. This reduces noise and helps speed analysis of the data. The lesson: Look beyond the trees to view the entire forest when it comes to metrics.

By adopting an end-to-end approach to DataOps and leveraging specialized tools at every step of the pipeline, Uber is pioneering the use of AI in its large-scale consumer applications.

Netflix: Offline First, Then Online

Content recommendation is key to the user experience in the Netflix app. Highly relevant content makes the experience personal and drives higher engagement. However, making this happen behind the scenes involves working with large quantities of data and overcoming obstacles every step of the way.

Netflix uses Spark to power content personalization. While the company has existing models in production, it always is testing new models and hypotheses to improve on existing ones. However, every new model needs to be tested against an older model and should be proven to be better before being implemented. Netflix does this model testing offline rather than online in the live app. The company makes a copy of historical data and performs offline feature generation on this data. The features are stored in a Hive store in AWS S3, and subsequent feature generation and model training is done in Spark. Once a new model is ready, it is run in parallel with a live model and, if it performs better, it is deployed.

Key to the success of this operation is the logging of historical facts from online to offline. This includes Netflix-specific facts such as video, user and computation facts. Once this historical data is stored, a data worker is able to run simulation tests against it using the newly developed models. These simulation tests are a great way to test models without breaking things and save time by failing fast. Once tested and compared with live models, Netflix goes on to establish different SLAs for different microservice apps that these models serve. All this effort results in a highly relevant recommendation engine and a very personalized experience for Netflix users.

Airbnb: Tapping Into Related Data Stores

Airbnb uses AI to improve the search rankings and relevance of its “AirBnB experiences” offering. The company started simply, only recording users’ daily searches, clicks and bookings. Soon, it created features on top of this raw data, including features such as experience duration, price of experience and user reviews, which would help build models. Airbnb used a ranking model to give weight to experiences that had a better conversion rate, better user reviews and a lower price than those with just a higher booking volume. This improved experience bookings by 13%.

Going further, Airbnb tapped into the other user data it had—homes booked by Airbnb users—to further personalize the ranking of experiences. This is where things get interesting, as AirBnB is able to show experiences that are more likely to match a user’s interests. This is only possible by looking beyond a single data store and looking for relevant data that may exist elsewhere in the organization. This personalization further improved experience booking by 7.9%.

Similar to Uber, Airbnb uses a combination of offline and online scoring for models. While the historical data is great to get started with and run basic simulation tests, online scoring unlocks additional features such as user location, search filters and login status that wouldn’t otherwise be available offline.

Conclusion

AI is changing everything, and DataOps is no exception. By helping companies to make sense of their data more quickly and with less reliance on human effort, AI drives faster, more consistent results.

The good news for most of us is you don’t need to be a major tech company such as Uber, Netflix or Airbnb to take advantage of AI-driven DataOps. Tools such as Unravel are making AI-powered data insights practical for organizations everywhere, without requiring them to build bespoke DataOps solutions.

This sponsored article was written on behalf of Unravel.

— Twain Taylor

July 16, 2019
Building Continuous Compliance into DevOps

“Continuous” is one of the operative words of DevOps. A major goal of DevOps is to make all processes continuous, which means having them proceed smoothly and constantly to avoid delays or pauses within the software delivery process.

You’ve probably already heard of the importance of continuous integration and continuous delivery. But the importance of continuousness doesn’t end there. It extends to every component of the software delivery process, including compliance.

To illustrate the point, let’s take a look in this article at what continuous compliance means and how to achieve it.

Defining Regulations and Compliance

Regulations and compliance are two sides of the same coin. Regulatory bodies put in place regulatory laws and policies that are aimed at the benefit of the broader economy and end consumers. Organizations under the purview of these regulatory bodies must put a compliance framework in place to meet regulatory requirements.

Here are three of the most widely applicable regulatory requirements that organizations commonly need to adhere to today:

HIPAA

HIPAA, or Health Insurance Portability and Accountability Act, is applicable to healthcare organizations. It concerns the handling and protection of PHI data (Protected Health Information). The costs for mishandling healthcare data are steep for users. According to research done by Accenture, 26% of healthcare consumers were subject to data breaches, and it cost each victim an average of $2,500. Stats such as this make a strong case for HIPAA compliance.

PCI DSS

The PCI DSS (Payment Card Industry Data Security Standard) is a regulation for the financial services sector. It governs the use and handling of users’ financial data, such as credit card information and bank account information.

GDPR

The GDPR (General Data Protection Regulation Act) went live in the European Union in mid-2018. It defines policies related to how organizations handle data of users in the European Union. This includes giving customers the right to erase all their data from a company to ensure the organization doesn’t have indefinite possession of the data and to ensure confidentiality of users’ private information.

Why Continuous Compliance?

Cloud-native computing brings new complexities to how applications are delivered and how they handle user data. For starters, the scale of data flowing through the system at any given time is now much higher. How organizations and their applications manage this data is critical to compliance.

Audits can be outdated the very next day when dealing with such dynamic systems. For example, when new releases are deployed continuously, it’s easy for one release to expose an endpoint to a third-party application and leave sensitive data accessible to outsiders.

The regulatory requirements themselves change every few months. It’s important to keep track of these changes and adapt your systems to still be compliant. In light of this, it’s necessary to adopt continuous compliance as part of any DevOps workflow.

Achieving Continuous Compliance

Two Goals: Security and Speed

It’s easy to think of compliance as being about simply meeting regulatory requirements. However, this is far from true. When done properly, compliance also empowers your organization to operate at a pace that encourages innovation. Every organization that adopts DevOps wants to be secure and move fast at the same time. Continuous compliance is the way to achieve both these goals.

Compliance from Day One

Usually, compliance is an afterthought. However, continuous compliance requires that DevOps teams start their design and development with compliance in mind. This includes having clarity on the exact requirements, down to the fine details. With this in mind, the team can move forward to build applications that meet these requirements. To have this kind of clarity, the various teams, including business leaders, need to speak a common language and have common terms to describe the different parts of compliance.

Continuous Testing

Testing is essential to compliance. In the DevOps world, testing has undergone numerous changes. The good thing is that these changes all support continuous compliance. First, testing has shifted to the left of the development pipeline. With testing happening earlier, it’s easier to catch errors and vulnerabilities before they reach production. Second, tests are increasingly automated. This makes them predictable, measurable, repeatable and compliance-friendly.

Automated Compliance

Your compliance verification and enforcement process should be as automated as possible. Toward this end, integrating compliance checks into the CI/CD pipeline is a best practice. For example, make vulnerability scanning part of the CI/CD process by integrating it with your CI server so that checks are performed at build time automatically.

The Right Data Hierarchy

All data isn’t equally important. Some data is more sensitive. This is why you need to organize and categorize all the data in your systems. Once categorized, you can define policies to govern different types of data. This includes encrypting data at the appropriate level—and not just in transit, but also when data is at rest.

Track Access Control

In the effort to achieve control over compliance, identity and access management (IAM) plays a critical role. It helps define who is allowed to access data and what changes they’re allowed to make. When assigning access, it’s important to assign it according to teams or roles and not according to individuals. This makes IAM policies scalable and easier to control. Putting in place streamlined IAM policies negates the need to share passwords and other sensitive information. Every user can access only the data they need, and not more. This is the principle of least privilege in action.

Track Change History

Beyond IAM policies, it’s essential to maintain a change history for all users and parts of the system. The best way to implement this is to use log data as the source of truth. It delivers deeper visibility than mere monitoring events and help to troubleshoot incidents. Logs have always been a cornerstone of good compliance, and in today’s cloud era, they continue to play a key role.

Conclusion

Achieving compliance is challenging in any environment, but when you embrace DevOps, compliance presents special difficulties due to the speed at which workflows move and the importance of making processes continuous. Implementing continuous compliance takes effort, but the rewards justify it. Not only will your organization stay on top of regulatory requirements, but it will be better positioned to move quickly and innovate.

To put continuous compliance into practice, you need the right tool for the job. Symantec Cloud Workload Assurance (CWA) can help. Learn more about CWA features in this data sheet, and sign up for a free trial to see how CWA can help secure your cloud.

This sponsored article was written on behalf of Symantec.

— Twain Taylor

June 25, 2019
Building a Security Feedback Process for DevOps
The last few years have seen some major slip-ups in the security space among all major cloud providers, resulting in uncertainty and speculation. That’s understanding; cloud security is an extremely complicated subject as enterprises build and deploy applications faster than ever before to keep up with business requirements. Most of the security issues that occur in the cloud today are around compromised accounts, identity theft, malware apps and, of course, data breaches, which are business-critical and showstoppers, in many cases.

Given the dynamic environment of DevOps and the nature of the cloud, it’s a complex problem to address and fix. The most effective way is to embed security, or what is usually talked about as the shift-left of security, in the IT pipeline. If DevOps is the culture of collaboration to reduce risk by the size of change, DevSecOps is the automated security control built into each point to build a sort of self-defense mechanism.

DevOps is not about tools; it’s about philosophy and process. One of the most important processes to include to succeed at DevOps is a feedback loop that reinforces constant collaboration.

This is certainly true when it comes to security-related information. In a healthy DevOps organization, security problems that are detected at any point in the delivery pipeline are communicated quickly to all stakeholders, who can, in turn, respond accordingly.

In this post, we will look at the steps involved in building a security process that will ensure the right information reaches the right people quickly and that teams collaborate without duplicating efforts.

Automate Your Way to Better Feedback

Automation is the first step, and a no-brainer when it comes to DevOps. Without automated security tools for code analysis, configuration management, access control, vulnerability management and secrets management, it is very difficult to scale security in a dynamic DevOps environment. Manual efforts in the cloud are doomed to fail in many cases, as environments change rapidly. Hence, automate. The recommendation is to automate every security control and the entire feedback process as much as possible.

Manage Roles Right and Control Their Accesses

Identity and access management has become the linchpin in cloud security. Since it’s very easy to give people the wrong access, it becomes important to figure out who can access what resources. Access to information and resources must be secure, yet easy to obtain. All access should be given to a group rather than an individual. Mapping security access to the organization’s hierarchy is an effective way of establishing a communication loop. The right information reaches the right group of people. It is important to be able to answer questions such as the following to ensure the communication loop is efficient:
- Who can delete this VM?
- What are the resources a certain user has access to?
- Who has service accounts access?
Tools that show a relationship between users, groups, roles, permissions and resources help answer these questions.

Encrypt Secrets, Manage Their Keys

Another important step to building an effective communication cycle is controlling access to application-level secrets. Security can be improved by tightening information flow between relevant groups, which can be accomplished through creating and controlling access to secrets using principles of least privilege. Access keys to those secrets can be kept in a centralized secrets management tool or a key management tool. The rotation of these keys can be automated as often as required.

Designing for Failure and Proactively Managing Vulnerabilities

Though security personnel may cringe at the mention of the word “failure,” designing for failure means thinking ahead and having a plan B. The cloud is dynamic by design and things happen at an incredible pace, often resulting in issues of elasticity, configuration and cloud power.

Context becomes an important parameter for managing vulnerabilities because there are multiple vulnerabilities at any given time. Automated vulnerability management and configuration management solutions are available to take the complexity out of protecting cloud environments. Automation capabilities and continuous monitoring provide deep insight, intelligent recommendations and continuous protection of the cloud, thus ensuring effective management of information in the feedback cycle.

Log Everything — Everything

Just embedding security to shift left is not enough to ensure security. It is important for all relevant collaborating groups to know the status when some code is deployed. The primary source of visibility and feedback comes from logs. Effective logging strategy is the paramount attribute of security design. Logging should be enabled everywhere possible: data access logs, identity logs, admin activity logs, logs within the cloud environment, OS, network platforms, etc. Logs, though cumbersome and volume-heavy, are non-intrusive and a critical visibility tool. You need to know what’s going on before deciding to do something with the event itself, which brings us to the next step: monitoring.

Monitor Those Events

Testing departments often seem paralyzed with too many flags, which prevent them from prioritizing critical issues. Having log and event data is an important first step, but the absolutely necessary next step is to relay them into an automation strategy that will separate the unimportant, voluminous issues from business-critical priorities. Automated monitoring for events triggered makes the feedback cycle more effective. Otherwise, logs can become noise—a copious amount of noise.

Alerts and Notifications

We embed security in the code. We manage access and roles. We turn on the logs and monitor them. An event occurs. Now, who do we alert? An effective alert notification policy will ensure that notifications are sent to the right group of individuals, depending on the notification filters—the level of criticality and relevance of the issue type. Notification policies specify the conditions that trigger a notification that will be sent to the recipient. Notifications can be sent by email, SMS, voice, push messages, etc. A recipient can then acknowledge the alert, which indicates to other users that someone is working on the issue, thus avoiding duplication of efforts.

Conclusion

To conclude, automating security controls and feedback cycles enables a productive DevOps ecosystem by exposing vulnerabilities early in the product life cycle. Automation, streamlined communication and appropriate response to priorities ensure availability, network connectivity and resilience. At the same time, they reduce the possibility of a data breach and duplication of efforts. At the heart of everything is the ability to deliver code in a secure and reliable way to meet ever-evolving business needs with agility.

To see how Symantec can help maximize security in a DevOps environment, check out a free trial of Symantec Cloud Workload Assurance.

This sponsored article was written on behalf of Symantec.

— Twain Taylor
June 20, 2019
The DevOps Security Stack
The whole idea behind DevOps is automation. DevOps automates the development process by eliminating or minimizing human error. If an error occurs, the applications fail quickly so the errors can be resolved promptly on a smaller scale. DevOps and cloud-native applications complement each other perfectly.

Even though DevOps offers a more efficient and faster way to develop and deploy applications, security remains an issue. On paper, DevOps and cloud-native applications might be more secure than their traditional counterparts, but the reality is not that simple. With the newer, more complex, highly distributed infrastructures common to DevOps come new challenges that need to be identified and addressed.

This article walks through those challenges to highlight what it takes to secure a DevOps workflow. I won’t focus on specific tools because DevOps is not about specific tools; rather, I’ll focus on the components of DevOps workflows that present special security challenges and explain how to address them.

The Vulnerabilities You Just Can’t Ignore
1. Careless use of recycled code
One way DevOps improves developer productivity is by letting developers recycle code from previous projects or open source repositories such as GitHub. But without proper screening and sanitization, these pieces of code can pose threats to an application.
1. Multiple platforms make the attack surface larger
When deploying code in the cloud, you can’t use traditional security services. You need to rethink your security strategy. DevOps teams leverage various platforms, from serverless computing to microservices to multi-cloud in their applications. There’s no single solution to secure cloud-native applications. These applications are highly distributed and have various components, so organizations need a multifaceted approach to better secure these applications.
1. The dynamic nature of cloud-native applications doesn’t help
Cloud-native applications are continuously integrated and deployed, which makes it difficult for security teams to identify and mitigate risks. Traditional security tools can’t match the sheer velocity, scale and dynamics of cloud-native applications, leaving them useless.
1. Secrets need to be secured
When following the DevOps approach, security professionals need to create privileged accounts and login details and share them over business networks automatically. With serverless applications and the cloud, security teams don’t have a traditional location such as the operating system to execute security policies. A host of useful data, such as keys, storage account credentials, secrets, database passwords and embedded passwords, are stored in repositories. It’s crucial this data is kept extremely secure, as attackers can use this information to cause some serious damage.
1. Containers can leave your applications more vulnerable
Since the microservice approach involves a distributed infrastructure, it exposes your system to the network, which makes it easy for attackers to sneak into the system. Containers can be spread across different systems, which makes the threat landscape even larger. Containers are highly replicable, so if there is a vulnerability in one microservice, it can get replicated every time the source code is used.

Using open source software in containers can make way for an increase in vulnerabilities. DevOps teams should make sure unauthorized containers are not used in production. These containers can be used by attackers to launch an attack on the entire application.
1. Hosts aren’t automatically safe
Even if containers are properly secured, the hosts they run on are vulnerable to new threats and day-zero attacks. Container runtime should be up-to-date to avoid risks that can lead to container escape. This can help attackers to take control not only of a container but also the host operating system. So, it is important that hosts are given appropriate protection.
1. Kubernetes clusters need additional security
Kubernetes is a widely accepted container orchestration platform. However, it’s difficult for security to be enabled at multiple layers. Kubernetes uses APIs to manage containers, and recently, it was discovered that K8’s API server is quite susceptible to attacks—attackers can make use of the API server to perform malicious activities or install malware in the application.

Running multiple workloads on one cluster is not a good idea. Sensitive workloads should be run on a dedicated set of machines to avoid attacks through less secure neighboring applications. There’s also a need to secure sensitive metadata, which can be stolen and used to change privileges in a cluster, thereby paving the way for unauthorized changes in an application.

DevSecOps: The Future of DevOps Security

In traditional applications, security holds less priority, and security policies are always employed after development is completed. But with DevOps, security can’t be an afterthought. Companies depending on the DevOps approach need to make security their top priority. One of the ways to make sure security is in the foundation of a DevOps implementation is a DevOps security stack. To employ the DevOps security stack, IT teams no longer should be walled off from the DevOps team.

Security experts’ involvement can help them gain insights into what the application is and how it’s supposed to function so they can identify risks and take steps to mitigate them. This DevSecOps approach has become popular. DevSecOps is a collaboration between the development, security and operations teams who work together to ensure security is at the root of an application, not just on the surface.

Symantec Cloud Workload Protection: A Modern Solution for Modern Problems

Most organizations use hybrid cloud storage comprised of workloads distributed among public clouds, private clouds and on-premises, which can lead to an increased attack surface and vulnerabilities.

Symantec Cloud Workload Protection (CWP) helps organizations monitor and protect their workloads, no matter where they reside. With CWP, organizations don’t have to look for multiple products to meet their many security needs. CWP offers a single console to monitor and manage security across various platforms. It offers automatic discovery of workloads across AWS, Azure and Google Cloud, and visibility into security postures and software, which enables automatic workload monitoring and protection. With continuous delivery workflows and malware prevention, CWP is essential for modern software development.

Sign up for a free trial of CWP.

— Twain Taylor
June 13, 2019