devopsy.kinsta.cloud

Author: Chris Tozzi

  • Practical Approaches to Long-Term Cloud-Native Security

    Practical Approaches to Long-Term Cloud-Native Security

    There is no shortage of advice out there about how to secure modern, cloud-native workloads. By now, most developers and IT engineers who work with cloud-native deployments have heard all of the mantras about DevSecOps, shift-left security, multi-layer defenses and dynamic baselining (to name just some of the key concepts that are driving IT security conversations these days).

    One thing is to talk about security best practices and another is to design a cloud strategy that makes it not only possible but also easy to implement them. Even more challenging is planning a strategy that facilitates security best practices over the long term.

    Keep reading for tips on meeting these challenges and devising a long-term security strategy.

    Security Is a Long Game

    It’s easy to think of security as something you have to do in real time. After all, threats and attacks usually happen suddenly, and reacting to them quickly is key to preventing serious damage.

    If your security strategy centers on finding and remediating threats as they appear, you end up stuck in what is essentially a break/fix mode. You’re constantly reacting, rather than being proactive.

    A much more effective security strategy is one that minimizes the threats you face in the first place. That type of strategy requires long-term planning.

    Sure, you will always need to be prepared to detect some threats that you didn’t anticipate, and react quickly in the event a breach occurs. No security plan is perfect, and the unexpected will sometimes still happen. But by focusing as much as possible on long-term security solutions that stop most threats from materializing, you end up with a much safer and more reliable security posture.

    Building a Long-Term Security Strategy

    What does it actually take to implement a security strategy that protects you over the long term? It all boils down to four elements: data, infrastructure, processes and culture.

    Data

    For many organizations, data stored in the cloud is the workload that poses the greatest risk. It’s the reason why there is a seemingly never-ending stream of headlines about major security breaches that involve the theft of sensitive data stored in the cloud.

    Therefore, mitigating threats to data in the cloud is a critical requirement for long-term security. Some best practices in this regard include:

    • Assess your data: Data security starts with knowing what is in your data, and how sensitive the data is. Data cataloging can help with this process, but so can tools such as Amazon Macie, which helps identify personally identifiable information with cloud-based data.
    • Access control: Access control frameworks are another crucial line of defense against cloud-based data breaches. Just remember that simply enabling IAM is not enough; you must also audit IAM policies to avoid misconfigurations that could lead to a breach (which was the lesson learned by Capital One, among others).

    Infrastructure

    These days, we tend to treat infrastructure–meaning the cloud-based and/or on-premise data centers that host workloads–as a relatively generic and interchangeable part of the solution stack. But while it is true that, generally speaking, no one cloud or data center is inherently more secure than another, the way you design your infrastructure plays a key role in your ability to secure modern workloads over the long term.

    Best practices on the infrastructure front, for long-term security include:

    • Immutable infrastructure: Embrace infrastructure platforms, such as ECS or EKS, that make it easy to deploy and update applications in an immutable way. Immutable building-blocks may not work for all use cases, but where possible, they reduce the number of variables and handoffs you have to contend with in order to deploy or update an application (and the more variables and handoffs, the greater the chance of an oversight that will create a security vulnerability).
    • Access control: While IAM frameworks can help prevent some types of unauthorized access, you can also increase the security of your infrastructure using Access Control Lists. A best practice is to adopt a whitelisting approach that blocks all traffic by default, and allows only explicitly trusted hosts.
    • Avoiding bloat: Cloud-native infrastructure makes it easy to spin up virtual machines, databases or other infrastructure components that you don’t truly need, and keep them running. Doing so increases your attack surface. For that reason, identifying and shutting down unused infrastructure is critical for ensuring long-term security. It also helps cut cloud costs, but that is another topic.
    • Parity: In order for developers, ITOps and security teams to be able to communicate and coordinate effectively, they should all be working with the same types of infrastructure environments. Collaboration becomes much more difficult if, for example, you use an on-premise data center for development, then deploy production workloads to the cloud. Avoid this by striving to create parity across your infrastructure whenever possible.

    Processes

    Processes are the second key ingredient in creating a long-term security plan for cloud-native workloads. Obviously, the processes you use will reflect, in part, your particular workloads and tools. But no matter your situation, your processes should be designed with the following security goals in mind:

    • Consistency: Your IT organization may consist of different teams, each with different responsibilities and agendas. Nonetheless, to the extent possible, all teams should follow the same procedures when developing, testing, staging and deploying applications. Doing so reduces the chances of variables or oversights that can undermine security. You can help achieve this consistency by creating and enforcing IT governance procedures across the organization.
    • Shift-left: Processes are the part of your IT operation where shift-left security can have the greatest effect. Shift-left security means making security a priority from the start of the application delivery pipeline. Importantly, however (and this is a point that some organizations overlook), doing shift-left security correctly also means bolstering security operations at later stages of the pipeline, too. Don’t just shift security left and call it a day; aim to make security a primary consideration at all stages of your delivery chain.

    Culture

    Culture is something that can be difficult to formalize; indeed, if you try to stuff cultural values down your employees’ throats, you risk compromising the whole point of having an organic culture in place. Instead, you want to encourage your team members to naturally embrace values that promote a culture of security. Strategies that can help achieve that include:

    • Bug bounties: Incentivize your team to look for and address security issues by hosting bug bounties for your organization’s workloads. For this purpose, “bug” should be defined broadly to include not just security bugs within code, but any kind of configuration issue in your infrastructure, tools or applications that could lead to security vulnerabilities. That way, your bug bounties can include not just developers, but all members of the IT organization.
    • Encourage shared ownership: A culture in which each engineer owns a specific application, infrastructure or process is one that limits transparency and opportunities to address security risks. Strive instead to promote shared ownership of IT assets so each team member knows his or her work may be reviewed by others, which helps to encourage best practices and reduce security issues. In essence, these are part of the values that DevOps and DevSecOps prioritize.

    Conclusion

    By designing infrastructure, processes and cultural practices that promote security, you put your organization in a position to optimize security over the long term. Planning ahead for security is the only way to escape the break/fix cycle of responding to vulnerabilities as they are discovered, which leaves you always treading water and never pushing the needle. You won’t be able to prevent all security issues, but you can greatly reduce the number that crop up by baking security into your infrastructure, processes and culture.

    This sponsored article was written on behalf of Eplexity.

    — Chris Tozzi

  • Why AWS Cost Optimization Is About More than Saving Money

    Why AWS Cost Optimization Is About More than Saving Money

    Why is it important to track and monitor cloud costs? The obvious answer is it helps you save money—and everyone wants to save money.

    Yet, cost plays a much larger role in your cloud journey. If you think about cost only in terms of how much you are paying and what you are getting in return, then you’re missing much of the value that careful cloud cost control can provide.

    Let’s take a look at all of the reasons why monitoring and optimizing costs is critical for a successful AWS strategy.

    What Is Cost Optimization?

    In AWS and other clouds, cost optimization is the art and science of identifying and addressing inefficiencies in the way you are using resources.

    Those inefficiencies come in many forms. They could be an EC2 instance that offers more resources than you need for a given workload, which could therefore be replaced by a different, less costly instance.

    They could be a result of using one type of application architecture, like workloads running directly on virtual machines, when another, such as serverless or containers, would deliver the same performance for less overall cost.

    They could be caused by failing to take advantage of the best opportunities available for hosting a given workload. For example, you might be using S3 Standard for storage when S3 Glacier would meet your needs just as well, at a lower cost.

    By identifying these sorts of problems, you can take steps to spend less while maintaining the same level of performance for your cloud workloads. A basic best practice is to use tools such as AWS Trusted Advisor to help ensure that your infrastructure is set up in a cost-efficient way from the start.

    Cost Optimization Insights

    These tools only go so far, and they are not the be-all, end-all of cost optimization. They are designed simply to help choose the right type of configuration for a given workload. However, cost monitoring as a whole goes further, and delivers several other important types of insight into your AWS workloads and strategy.

    Rogue Infrastructure

    By its nature, rogue infrastructure—meaning use of infrastructure for purposes not officially authorized by your organization—is hard to detect. If it wasn’t, it wouldn’t be very good at being rogue.

    If you monitor cloud costs carefully, however, rogue infrastructure will have a hard time hiding. If employees spin up a virtual server in the cloud for personal use, or create storage buckets for organizational data that is not supposed to exist in the cloud, you are likely to discover it when you perform cost optimization operations designed to help identify workloads that should not be running.

    Having a strong IT governance policy in place that requires all cloud-based resources to be tagged is another way to help prevent the creation of rogue infrastructure, and to make unauthorized resources easy to detect. When possible, tagging should be automated to ensure the fastest and most consistent results.

    Security Risks

    Although cost optimization is certainly not the only tool you should use to help identify security issues in your cloud workloads, it provides some useful insight that other tools might lack.

    For example, if you notice that your bills for a certain application or service have increased due to heavier usage without a corresponding increase in legitimate requests, it could be a sign of brute-force attacks or other unauthorized access attempts.

    Neglected Projects

    When was the last time you evaluated each of your applications to ensure it was running as efficiently and securely as possible?

    If you don’t know because you don’t regularly do this, cost optimization can help ensure that you do recognize workloads that could stand to be reconfigured. If you discover that you are paying more than you expect for a given workload, or that one workload’s costs are rising more quickly than those of others without a clear reason, it’s probably time to take a look at that workload and assess whether it should be scaled up or down, migrated to a different type of service, or otherwise adjusted to operate more efficiently.

    Operational Inefficiencies

    Finally, cost optimization can help you identify inefficiencies in the way your organization is run. That is because fees charged by AWS that you could have avoided but didn’t might reflect larger inefficiencies within the organization.

    For instance, consider AWS data storage costs. If your AWS cost analysis shows you are paying early-deletion fees for data stored in S3 Glacier, you should determine why that is happening. It could be simply because you should be using a different storage class, but it could also be because employees are deleting data sooner than intended.

    Conclusion

    Saving money by being cost-efficient should always be one of your goals. But running your overall business in an efficient, transparent manner is another. AWS cost optimization can help you achieve all of this.

    This sponsored article was written on behalf of Eplexity.

    — Chris Tozzi

  • Optimizing AWS Performance Over the Long Term

    Optimizing AWS Performance Over the Long Term

    Ask most folks how to optimize performance on AWS, and they’ll talk about things such as autoscaling and rightsizing.

    Those tools are certainly part of an effective AWS performance optimization strategy. On their own, however, they are not enough to guarantee performance and reliability over the long haul.

    That’s because tools and processes such as autoscaling and rightsizing only help you optimize the performance of applications that are running currently, or are about to be deployed. They do little to ensure that performance remains optimal—especially as cloud services, cost structures and architectures evolve.

    With that challenge in mind, let’s discuss how to get the most out of AWS performance over the long term.

    What is AWS Performance?

    Before delving into long-term AWS performance strategies, let’s make clear what we mean by performance. A high-performing application is one that:

    • Meets or exceeds user expectations regarding responsiveness and speed.
    • Meets or exceeds SLA requirements for availability.
    • Is able to scale seamlessly as performance requirements change.
    • Does all of the above in a cost-efficient manner.

    These aspects of a high-performing AWS application are important to emphasize because they reflect a holistic approach to performance. Sometimes performance is defined narrowly, in terms of application responsiveness and/or availability. Those are part of the performance equation, but in order to maximize performance over the long term, you need to think about other dimensions of performance, like the role played by scalability and cloud spend.

    Long-Term AWS Performance Considerations

    To optimize AWS performance over the long term, you must take a variety of factors into consideration.

    Handling AWS Service Changes and Upgrades

    AWS is constantly evolving. A performance strategy that works well today may not be as effective tomorrow if AWS introduces a new service or changes the features of an existing service.

    The challenge here lies not just in updating your app and your cloud configuration as AWS changes how a particular service works. It also requires constantly evaluating whether the service you are using is the best fit for your application.

    For example, think back about five years to when AWS Lambda (AWS’s serverless computing service) appeared. At the time, if you were running your apps inside virtual servers, you might have been able to improve overall performance by moving some of the workloads to serverless functions—not because anything in your virtual servers had become less efficient, but because better efficiency opportunities opened up with the addition of a new AWS service.

    Thus, being constantly aware of the various services in AWS and the opportunities they offer is key to optimizing long-term performance.

    Plan for Changing Cost Structures

    AWS not only changes its menu of service offerings frequently, it also updates pricing. Since cost optimization is one key component of performance optimization, you must ensure that your cloud workloads are running in the most cost-efficient way even as cost structures change.

    Staying aware of new cloud services (such as lower-cost S3 storage tiers) when they appear is one way to do this. But you also need visibility into the tremendously complex world of AWS pricing in all of its region-specific details.

    Plan Long-Term for OSS Dependencies

    Open-source software is something else that is constantly changing. If you rely on open source code to help run your AWS applications, you need to stay on top of changes in the projects you depend on.

    If you are using the same version of an open-source application or module that you built into your application when you first deployed it, you may be missing out on performance optimization opportunities that have arisen since then.

    Here again, constant awareness of and visibility into the complex open-source ecosystem is essential for ensuring that you are not missing out on optimization opportunities.

    Application-Specific Performance Monitoring

    Every application is a special snowflake and you need to keep that in mind when it comes to the way you track and optimize application performance.

    The metrics or KPIs that work for optimizing the performance of one app may not be ideal for another. The pre-deployment testing routines you use for applications might vary, too.

    So, make sure to tailor your monitoring strategy to your applications. Doing so is the only way to ensure you have the greatest, most relevant level of visibility into application performance over the long term.

    Backup and Disaster Recovery

    No matter how well your AWS workloads perform, sooner or later something will go wrong and they will fail. Whether the failure leads to a critical availability disruption or a mere hiccup hinges in large part on whether you have a backup and disaster recovery plan in place beforehand.

    For AWS apps, an effective backup and recovery plan entails more than just backing up data to storage buckets and downloading it to rebuild servers. It should also take advantage of opportunities like the ability to create image-level backups of virtual servers and restore them automatically to EC2 if disaster strikes.

    And of course, as AWS changes, you’ll need to keep your backup and recovery strategy in sync.

    Changing SLA Requirements

    Last but not least, keep your SLAs in mind. The SLAs you have to support today could change in the future—and by extension, so will the levels of availability and responsiveness that your users expect.

    For this reason, make sure your AWS performance strategy is capable not only of meeting the SLAs you currently have in place, but also adapting and scaling as SLA requirements become more rigid.

    Conclusion

    Although we tend to think of performance within the context of the present, it’s really a long-tail game. Sure, you can autoscale your workloads or use rightsizing tools to help choose the best type of EC2 instance for right now. But truly maximizing performance requires you to think longer-term and be prepared to react with agility as new performance challenges and opportunities arise.

    This sponsored article was written on behalf of Eplexity.

    — Chris Tozzi

  • Why Integrated Infrastructure Is the Key to IT Success

    Why Integrated Infrastructure Is the Key to IT Success

    At first glance, your IT infrastructure might seem like your house’s basement. It supports everything, but you don’t pay much attention to it or spend much time or energy trying to make it beautiful. Instead, you treat it as a generic component and lavish your attention on other parts of your IT landscape (or your house, as it were).

    But the fact is that infrastructure is not so simple and generic. The way you design your infrastructure, as well as your ability to integrate it with the ever-changing set of tools that you need to keep workloads running efficiently, plays a critical role in defining overall business success.

    To prove this point and encourage you to give your infrastructure some much-needed love, keep reading for an overview of why well-integrated infrastructure is so crucial, and why implementing an infrastructure that integrates seamlessly with the rest of your solution stack is an important best practice.

    What Is Integrated Infrastructure?

    By integrated infrastructure, we mean infrastructure that seamlessly connects with the entire ecosystem of tools you use to deploy and manage applications.

    To put that into context, consider some examples of how infrastructure interfaces with tools:

    • Your CI/CD pipeline needs to be able to integrate effectively with the infrastructure that hosts CI servers, testing tools and build tools.
    • Release automation software must be able to deploy seamlessly to the infrastructure that will host live applications.
    • Monitoring and performance optimization tools need to work easily with whichever infrastructure hosts your workloads, since monitoring the underlying infrastructure is one critical component of application monitoring.
    • Security and access-control tools must be able to apply security policies and restrictions to host infrastructure to help keep applications secure.

    The list could go on, but you get the idea: an integrated infrastructure is one that can easily interface with all of the tools you use to create, deploy, manage and secure the workloads you host on that infrastructure.

    Agnostic Infrastructure Versus Integrated Infrastructure

    You may be thinking, “It’s 2019, and most infrastructure is agnostic. My tools don’t care which cloud I use to host my workloads.”

    You’d be right that most modern, cloud-native infrastructures are designed to be agnostic toward the tools that are used with it. Although there are certainly exceptions, the majority of infrastructure solutions available today—whether they are from a public cloud vendor, or local infrastructures built using standard operating systems and hypervisors—can be configured to work with pretty much any mainstream tool you throw at them.

    But agnostic infrastructure is not the same as integrated infrastructure. An integrated infrastructure is one in which the connections between your tools and your infrastructure are not only possible to create, but happen seamlessly.

    This difference is easiest to see if you compare public cloud vendors’ native tools with tools from third-party vendors that work with those clouds, but don’t always integrate seamlessly with them. For example, pretty much every modern APM tool can be configured to work with AWS. But setting them up takes time, and there is no guarantee they will always be compatible.

    In contrast, there is CloudWatch, AWS’s native monitoring tool. It falls far short of being a complete APM solution, but it is seamlessly integrated with any AWS infrastructure. You don’t need to configure or install anything to use it, and it scales automatically with your AWS footprint.

    Achieving Infrastructure Integration

    My point here is not that you need to choose between a feature-limited native toolset and a third-party one that offers more features but does not integrate as well. Instead, you should strive to build an infrastructure and a toolset that offers the best of both worlds: rich features and tight integration.

    The best way to do that is to take a toolset-first approach. By that, I mean identifying which tools you need and designing your infrastructure around them. That is preferable to the strategy that most organizations use by default, which is to choose an infrastructure (usually a cloud provider) and then figure out how to reconcile their toolset with it. Not only does this approach limit your choice and inflate your costs (because you may end up having to use native tools from your cloud vendor that are less cost-effective than third-party alternatives), but it also makes integration between your tools and your infrastructure more difficult.

    Before you go and migrate all of your workloads to one public cloud or another, identify the various tools you depend on and evaluate how well each of them integrates with the clouds (or other infrastructure solutions) available to you. You may find that you should choose an infrastructure strategy built on multi-cloud or hybrid cloud to achieve better integration with your toolsets. This type of approach will make infrastructure architecture more complex, but it enables better infrastructure integration, which delivers more value in the long run.

    Integrate for Today and the Future

    Keep in mind, too, the tools you use today can, and probably will, change in the future. Thus, you want to ensure that your strategy enables tight infrastructure integration over the long term.

    Here again, a multi-cloud or hybrid cloud strategy is probably the best approach for maximizing flexibility and integrability, although you’ll need to assess your specific needs by looking at your tools first, and then plan an infrastructure strategy that will accommodate them as they evolve and grow.

    Conclusion

    The bottom line is this: Although infrastructure might seem like a mundane and largely interchangeable part of your IT landscape, the extent to which it is well integrated with your tools can make or break the overall effectiveness of your IT strategy. Don’t choose infrastructure first and then shoehorn your tools to fit it. Instead, design your infrastructure architecture around the tools you need, and make sure it can continue to accommodate them as your strategy evolves.

    This sponsored article was written on behalf of Eplexity.

    — Chris Tozzi

  • Operational Excellence and the Success of Software Deployments

    Operational Excellence and the Success of Software Deployments

    When we talk about best practices for software reliability, the conversation tends to focus on optimizing the applications themselves and the infrastructure that hosts them. The driving idea is reliability must be baked into system architectures and infrastructure from the beginning.

    That’s certainly true. But by focusing too much on the design and implementation of applications, you run the risk of overlooking another crucial element for achieving reliability (not to mention agility and extensibility): a culture of operational excellence.

    It’s only by baking excellence into your organization’s operational culture that you can maximize reliability.

    Let me explain…

    Defining Operational Excellence

    Put simply, operational excellence is a mindset that is embraced across an organization to maximize outcomes and positive results.

    Operational excellence can be reinforced by specific tools and processes, but it’s ultimately a philosophy and a cultural principle. It must be integrated into your organizational culture in order to achieve its full effects.

    Operational Excellence And Software

    Operational excellence is a buzzword that you hear occasionally in the context of business management. It only rarely appears in conversations about software. Nonetheless, the concept has an important role to play in several respects, including making software more reliable and extensible.

    Uniting Disparate Teams

    One of the most pervasive challenges in modern software deployment and management is the fact that every deployment depends on multiple teams. Developers, IT operations, infrastructure engineers and business managers all have a role to play in ensuring that an application is a success.

    Getting all of these teams to work together can be a challenge. The ideal solution, according to the DevOps mantra, is to de-silo your organization by creating a single DevOps teams that oversees development, operations and everything in between. For some companies, that approach will work, but for others, single-team DevOps is not a realistic goal. There will always be some distinction between teams and specializations.

    Yet whether you have a single DevOps team, or multiple teams working toward a common goal, operational excellence can help you achieve the cultural unification necessary to help everyone advance the common good. Operational excellence serves as a cultural goal shared by all teams and team members during the software development and deployment process. By making excellence part and parcel of your culture, you gain a principle that can guide all of your teams, even if they otherwise share little in common culturally—which, generally speaking, is the case; developer culture is not the same as IT culture and certainly not the same as business culture.

    Operationalizing Best Practices

    Another key benefit of operational excellence is that it helps to ensure best practices are actually followed across the software deployment process.

    Most stakeholders in software development and deployment know what they should do when performing their jobs…but they don’t always do it. Your developers might churn out an inefficient function because they are under pressure to meet a deadline and need to deliver something that works, even if they know that they are not following coding best practices. Your IT team may fail to configure granular IAM permissions for a virtual server because they lack the time, even though they know that is not a best practice from a security standpoint.

    Instilling operational excellence into your teams helps to prevent these types of shortcuts. When a culture of excellence prevails, your team will follow best practices, even if they take longer.

    Continuous Improvement

    Human beings are naturally inclined to desire finality. Feeling like we will never reach the end of a task is discomforting (that’s why poor Sisyphus was so unhappy, for example). Yet, this discomfort needs to be managed if your organization is to achieve a culture of continuous improvement. Continuous improvement means your teams constantly find ways to make things better, even if they are already quite good.

    For developers and IT teams, this can be a tough pill to swallow. Developers or engineers who have achieved 99.99999 reliability for their application would probably rather feel proud of what they’ve accomplished than be told they need to add another nine to that figure.

    Still, striving to become even better is what continuous improvement requires. A culture of operational excellence can help ensure that your teams welcome this type of challenge rather than resent it.

    Collective Effort

    When it comes to software development and deployment, personal ownership of any part of the code or process is a risk to the organization. If only one programmer knows how a certain microservice works, or only one IT engineer has the power to create new databases, your organization will lose agility, or it could even end up with a hostage employee situation.

    Instead, software deployment should be as collaborative as possible. Everyone within a given team should understand and (in a pinch, at least) be able to perform everyone else’s job.

    A culture of operational excellence helps to ensure that your teams take a collaborative approach to the way in which they build and deploy software. Instead of letting each individual own part of the process and receive personal credit for its success, operational excellence encourages team members to think of their work as a collective process with collective responsibility for the results. That’s because operational excellence focuses on the success of the organization as a whole rather than individual employees or teams.

    Conclusion

    To be sure, choosing the right architectures, tools and people will do much to help maximize the reliability and effectiveness of your software, but those are only part of the solution. You also need a culture of operational excellence to unite your various teams behind a commitment to best practices, continuous improvement and collective pride in the applications they build and deploy.

    This sponsored article was written on behalf of Eplexity.

    — Chris Tozzi

  • What It Really Takes to Build a Reliable App

    What It Really Takes to Build a Reliable App

    What makes an app reliable? If you ask most IT professionals that question, their minds immediately go to uptime. That’s not surprising; after all, it’s fashionable for software and infrastructure vendors these days to boast about how many nines of uptime they guarantee.

    To be sure, uptime is one component of delivering a reliable application experience for developers and end-users. But it’s only one. In order to build reliability into your application patterns, you must think beyond uptime alone.

    Keep reading for an overview of all the factors that go into achieving reliability.

    What Is Reliability?

    A reliable application is one that meets the needs and expectations of everyone it serves. While those needs and expectations will vary from case to case, reliability is characterized by the ability of an app to:

    • Be accessible when needed.
    • Respond within the time frame needed.
    • Be updated or modified as needed.
    • Provide security and privacy to the extent needed.
    • Meet the needs and expectations not just of end-users, but of everyone else who helps create or support the app.

    Maximizing Reliability for Cloud-Native Apps

    Achieving these features for modern, cloud-native applications requires a multi-pronged approach. The following are the core considerations to address in order to build reliability into an app pattern:

    Uptime

    We’ll start with uptime, which is the most obvious aspect of reliability. Uptime refers to the amount of time that your application is available, at least to some extent (as we’ll discuss below, merely being available does not necessarily mean that the app satisfies other requirements of reliability).

    Maximizing uptime typically involves solutions such as distributing workloads across different servers or data centers (so if part of your infrastructure fails, others remain available) and using automated failover to move a workload to new infrastructure if it fails in one location.

    Culture and processes are part of the picture, too, since you need to make sure your team is prepared to respond quickly to any incidents that arise, in order to minimize downtime.

    It’s worth noting, by the way, there can be such a thing as too much uptime. If you reach the point where adding more uptime doesn’t deliver any additional value to your organization, then it’s probably time to stop. Adding another nine to your availability, just because you can, might be a poor use of resources. So, be sure to factor this part of the equation into your uptime calculations and strategy.

    Performance and Efficiency

    In order to meet stakeholder needs and expectations, an application must not only be available, but also able to respond within the time frame required by those stakeholders. A website that is up 100% of the time but takes 20 seconds to load each page is not a very reliable website.

    This is why performance testing and monitoring must be built into your application delivery chain. You should also ensure that you rightsize infrastructure (for example, by choosing the right types of cloud instances) in order to guarantee that your applications have enough resources available to perform adequately. (Of course, this priority must be balanced with cost-control.)

    Accessibility and Usability

    An application that is available all of the time and responds quickly may still fail to meet stakeholder needs if it is difficult to work with due to poor design.

    From an end-user’s perspective, user-experience testing is the most obvious way to help mitigate the risk of poor accessibility or usability within your applications. But keep in mind that you also need to think about usability from the perspective of your own team. Make sure that access-control systems, infrastructure architectures and documentation can be navigated easily. You don’t want an application or a delivery chain that is too complex for your team to be able to support effectively.

    Security and Data Privacy

    A reliable application is a secure application. There are many obvious ways to help secure applications, such as using vulnerability monitoring tools. But remember security is not just about finding vulnerabilities as they arise or deploying certain tools. You must also build security into the design of your infrastructure, processes and culture.

    Backup and Recovery

    You don’t need to be a seasoned IT professional to know that backing up data is important for achieving reliability. When something goes wrong–which it occasionally will, despite your best plans and efforts–having a backup in place often means the difference between experiencing a blip in service and a major catastrophe.

    The thing that can be easier to overlook is the importance of having a disaster recovery plan in place as well as a backup routine. Simply backing up your data isn’t enough; you must also know how you’re going to restore it to new application instances quickly if disaster strikes. If, for example, all of your cloud-based virtual machines go down, what is the exact process you’ll follow for standing them back up? Identifying the steps ahead of time–and, ideally, scripting them so the recovery process can be as automated as possible–is crucial.

    Also important is quantifying how often you need to back up data, which is determined by a metric called Recovery Point Objective (RPO), and how quickly you need to be able to recover it to avoid serious business disruption–determined by Recovery Time Objective (RTO). Along similar lines, error budgets, which define how much time you can tolerate your production systems being down, can help you define the available time monthly for making system improvements.

    Modifiability

    Few apps are deployed and then never modified again. Instead, they must be updated or scaled constantly to meet changing needs and demands. That’s why designing an application pattern that can be easily modified is critical for achieving reliability over the long term.

    In practice, modifiability entails having the right tools (such as automated deployment solutions) and the right processes (such as clear feedback loops between ITOps and developers) in order to decide efficiently what modifications to implement. It might also involve taking advantage of infrastructure technologies (such as containers) that make it easy to update a running application without imposing downtime on users.

    Conclusion

    Reliability is more complex than it may seem. No matter how many nines are included in your SLAs, you are not guaranteeing true reliability unless you also address requirements such as performance, usability and modifiability.

    This sponsored article was written on behalf of Eplexity.

    — Chris Tozzi

  • To Build a Healthy DevOps Culture, Look to Your Ecosystem

    To Build a Healthy DevOps Culture, Look to Your Ecosystem

    How do you do DevOps?  Here’s a hint: Don’t fixate on finding the right tools or implementing the right processes. Instead, think about the broader ecosystem in which you operate, the culture that prevails in that ecosystem and which parts of the culture you can borrow to help enable your DevOps transformation.

    This is true no matter which type of ecosystem you work in–even one that depends in part on mainframes. In other words, to quote from Rouan Wilsenach, writing on Martin Fowler’s blog, “Even with the best tools, DevOps is just another buzzword if you don’t have the right culture.”

    Keep reading for tips on what this means in practice, and how to build a successful DevOps culture by engaging your ecosystem.

    Tools and Processes in DevOps

    To be sure, tools and processes are a key part of DevOps. We’ve yet to see an organization that achieves continuous delivery successfully without the help of a continuous integration server or a continuous feedback process.

    But the reality is tools and processes are not what ultimately separates DevOps success from DevOps failure. Tools and processes help you to implement DevOps; but on their own, they don’t deliver the cultural priorities that allow DevOps organizations to thrive.

    This is an important point to digest. The market is teeming with tools pitched as critical enablers of DevOps, and there is no shortage of articles about why processes such as shift-left testing or de-siloing your team are important for DevOps.

    It would be a mistake, however, to assume that doing DevOps is as simple as implementing one of these tools and processes. If it were, we wouldn’t be spending so much time talking about DevOps in the first place, because it would be a trivial thing for anyone to achieve.

    DevOps Culture

    What matters above all in DevOps is culture. By culture, we mean the values and viewpoints that shape how your team approaches software delivery.

    If your team members don’t believe in constant collaboration and transparency as cultural values, no amount of continuous integration servers or real-time communication tools are going to enable you to achieve the type of team-wide collaboration necessary to support continuous delivery. Similarly, if your developers, software testers or admins don’t recognize the importance of doing continuous delivery in the first place, having the tools and processes in place to perform continuous delivery is not enough to ensure it actually happens.

    This is why instilling key cultural values is critical for DevOps. This isn’t an exhaustive, universally applicable list of essential DevOps cultural values, but most folks would include the following items in this category:

    • Collective accountability. Everyone on your team should assume responsibility for ensuring that software is delivered on time and meets expectations. Software delivery is everyone’s responsibility in DevOps.
    • A blameless environment in which the team as a whole, rather than individuals, owns the system.
    • In a DevOps culture, all team members should have constant visibility into what other members of the team are doing.
    • DevOps places a priority on minimizing manual effort. It promotes automation over allowing some team members to perform tasks manually in order to protect their turf or increase their individual value.
    • Collaboration and shared roles. In DevOps, no single engineer should exclusively own a particular task. Some people might bear primary responsibility for certain tasks, but at the end of the day, everyone should be permitted, qualified and willing to assist with any task.
    • Support from management for all of the above. Executives need to embrace the concept of collective ownership for IT processes, while also giving IT teams the flexibility to scale and change tools and processes as needed.

    Your Ecosystem and Your Culture

    How do you actually construct a DevOps culture founded on principles like those described above? Part of the answer lies in evaluating your current internal company culture, of course, and taking steps to change it.

    But another important part of the answer lies in your business’s ecosystem. After all, culture is not something that develops only on the basis of internal factors. Culture is influenced to a tremendous extent by what is going on around you.

    So, in order to build a healthy DevOps culture, think about what other companies you engage with are doing. In many cases, you can jump-start your DevOps cultural transformation by borrowing ideas from partners who have already been there.

    To be clear, I’m not suggesting you look only for partners who have won accolades as DevOps-first organizations, or startups that have had the benefit of coming of age when DevOps was already a big deal. Think also about established companies that have deep experience working with an array of different technologies, integrating those technologies and bringing them up-to-speed with modern software delivery practices.

    Those are the organizations that have sophisticated, organic cultures. They’re also the ones that know what it takes to update existing cultures to support DevOps. And they may be able to help you identify the specific tools and processes that will enable DevOps for your business.

    Building a Healthy DevOps Ecosystem

    As an example of what the process of constructing an effective DevOps culture might look like in practice, consider how you might approach this challenge if your ecosystem (like many today) includes a mix of modern, cloud-based infrastructure on the one hand, and mainframes on the other.

    This might seem like a difficult circle to square. Conventional wisdom tells us that mainframes may be difficult to integrate with modern DevOps processes.

    But that is not the case. IBM offers a range of solutions to help integrate mainframes into the rest of your ecosystem. For example, Z Open Development makes it possible to standardize your SCM and build processes for mainframes using modern, Git-based tooling. Likewise, Z Open Unit Test makes it possible to bring modern unit testing to mainframe applications. And you can even test and build mainframe apps on commodity x86 servers using Z Development and Test Environment.

    Of course, integrating mainframe infrastructure into the rest of your ecosystem using tooling like this also requires a culture and attitude adjustment. Developers and ITOps admins must move past the cliché that mainframes have no role to play in modern DevOps shops, or that they are too difficult to integrate into modern ecosystems. That’s not at all true and building a successful DevOps culture that embraces the mainframe means discarding this inaccurate viewpoint.

    Conclusion

    In short, succeeding at DevOps means adopting the right cultural principles to turn a DevOps toolset into an actual DevOps workflow. The good news is you don’t have to invent those principles from scratch. Look for an experienced ecosystem partner or partners who can help you in your DevOps cultural journey.

    — Chris Tozzi

  • Why and How to Collect KPIs for Z DevOps

    Why and How to Collect KPIs for Z DevOps

    It can sometimes feel frustrating to try to figure out how to do DevOps. That’s because DevOps is not about tools—there are lots of different tools that can help you succeed at DevOps. Nor is it about any really specific set of practices; although DevOps prioritizes things like automation and communication, it does not prescribe specific processes for enabling them.

    Instead, DevOps is really just about cultural values, which is a rather vague guideline for people who want to do DevOps. In this sense, DevOps can make practitioners feel a little lost, because they’re unsure how to measure whether they are succeeding on their journey toward DevOps.

    The fact that DevOps ultimately boils down to culture does not mean there are not specific points of information you can track and analyze to help assess progress on your DevOps journey. The specific metrics you’ll analyze will vary depending on your circumstances and the systems you use, of course. But to provide an example of how you can evaluate DevOps progress in the real world, let’s take a look at which types of key performance indicators (KPIs) you might focus on when doing Z DevOps.

    What Is Z DevOps?

    Z DevOps refers to a DevOps practice within the IBM Z ecosystem. Although Z is not typically the first technological niche to come to most people’s minds when they think of DevOps, the fact is more than half of enterprise transactions continue to run on IBM mainframes. The vast majority of structured business data also resides on these systems.

    Thus, bringing mainframe software delivery up-to-speed with DevOps culture is an important priority for many organizations. That’s what Z DevOps is all about.

    KPIs for Z DevOps

    Whether you’re just starting on your Z DevOps journey, or have been doing DevOps-based software delivery on the mainframe for a long time already, there are a variety of KPIs you can track to help assess how effectively your DevOps strategy is working, and find ways to make it even better. Remember, DevOps is all about continuous improvement and never settling for the current state of affairs.

    Deployment Speed: DevOps prioritizes faster software delivery. For that reason, being able to track how quickly you push out new software releases or updates is critical for measuring your DevOps success. In DevOps circles, this KPI is sometimes called Mean Time to Delivery, or MTTD.

    Keep in mind that truly continuous releases (meaning releases that are literally constant) are an unachievable goal. But by tracking your current deployments per week or month, you can measure how your deployment speed changes over time.

    Deployment Success Rate: Software deployments can fail for a variety of reasons, and achieving 100% success is not practical for most organizations. But you still want to strive to maximize your deployment rate. Anything around 90% is impressive in many cases. So, track how many deployments succeed and fail.

    Deployment Scale: Deployments vary greatly in size. One deployment might contain a few minor performance tweaks. Another might involve major interface or feature overhauls. In order to contextualize other deployment-related KPIs, it’s important to measure deployment scale by collecting information about the scale of your typical deployment.

    Scale in this context can be difficult to measure precisely, but basic metrics to track include information like how much new code is a part of each deployment, or which percentage of a deployment entails new features as opposed to bug fixes for existing features.

    Test Failure Rates: In most DevOps delivery pipelines, you will rely heavily on tests (especially automated tests) to verify that software is ready for delivery before it is deployed. When tests fail more often than expected, it can be a sign that developers are working too quickly or need more feedback about code quality. Tracking test failure rates can help you assess these issues and take action in order to minimize failures and keep deployments running on schedule.

    Team Performance: In addition to tracking overall speed and performance, it’s important to be able to track these KPIs on a per-team basis. Again, DevOps is all about culture, and some teams might need more help than others in embracing DevOps culture. By tracking deployment performance on a per-team basis, you are in a better position to identify teams that need more help, as well as those doing well and can serve as an example for others.

    Inter-Team Communication: Since DevOps is all about transparency and efficient communication across the entire IT organization, communication activity between different teams is another useful KPI to track. The data you collect on this front could include things such as emails or Slack messages exchanged between teams, or even meetings or phone calls. This data is not a perfect reflection of how effectively different teams engage with each other, but it provides some useful insight.

    Collecting DevOps KPIs for Z

    If you are doing Z DevOps, one challenge you’ll face is  many generic DevOps tools weren’t initially designed to work in the Z ecosystem. They were designed for other types of infrastructure and environments.

    That doesn’t mean the tools you need to do Z DevOps don’t exist, however. You just need to look beyond generic DevOps guides to find them.

    When it comes to collecting KPIs for Z DevOps, the go-to tool is UrbanCode Velocity. In addition to helping to automate and standardize the software delivery process for the Z ecosystem by providing release automation templates and tooling, UrbanCode Velocity lets you collect and track the various metrics that are important for taking stock of your Z DevOps operation.

    Because UrbanCode Velocity supports KPIs based on data gathered from Z DevOps pipelines, it can help to standardize your entire DevOps workflow, not just your Z DevOps effort.

    — Chris Tozzi

  • Shift-Left Testing, Continuous Integration and the Mainframe

    Shift-Left Testing, Continuous Integration and the Mainframe

    “Mainframe” is one of the oldest terms in tech. “Shift-left” is much newer.

    You may not think, then, that mainframes and shift-left testing have much in common. But you’d be wrong. Shifting testing to the left can deliver tremendous benefits, even in the context of mainframe applications.

    Let us explain.

    What Is Shift-Left Testing?

    Shift-left testing refers to the practice of performing more tests earlier in the software development lifecycle.

    Traditionally, most testing occurred just before software was deployed into production environments. Testing code at this stage is useful for ensuring it will behave as expected in production, but it comes with drawbacks.

    The biggest drawback of traditional testing is problems are difficult to fix if they are not discovered until just before software is ready to be deployed. At that point, addressing a problem within the code requires determining where specifically the problem exists within the code, removing that code from the application and replacing it with updated code—all without breaking other parts of the application that depend on the original code.

    Shift-left testing helps to address this problem by encouraging software delivery teams to perform tests earlier—typically, starting right after individual units of code are written. Being able to test earlier and more often is especially important in software delivery pipelines based on continuous integration/continuous delivery (CI/CD), where the goal is to roll out application changes on a nearly continuous basis.

    Since bugs that aren’t detected until just before release can take a long time to fix, a lack of shift-left testing puts organizations at risk of not being able to achieve the main goal of CI/CD due to constant delays caused by software quality problems. In addition, shift-left testing reduces the amount of overall end-to-end testing you have to perform.

    You Still Test on the Right

    It’s important to note tests performed earlier in the pipeline don’t replace the testing done just before deployment. They complement them and reduce the chance of having problems go undetected until right before deployment. In this sense, the term shift-left can be a bit misleading; it’s not really about shifting all testing to the left of the delivery cycle, as much as it is starting tests earlier, while continuing to test on the right of the pipeline as well.

    Shift-Left Testing and Continuous Integration on the Mainframe

    Shifting testing to the left makes it easier to fix code problems within virtually any type of application delivery pipeline based on CI/CD. But it can deliver especially critical benefits for software delivery teams striving to bring mainframe applications up to speed with CI/CD.

    There are a few primary reasons why. One is mainframe applications are usually written using older programming languages that were not designed to help developers avoid mistakes. This isn’t to say mainframe languages are especially prone to errors; they’re not. But compared to a language such as Python, which is designed to enforce good coding habits, a language like COBOL doesn’t exactly require programmers to be highly disciplined when they’re typing out their code. Thus, it’s especially important to be able to catch bugs earlier within code written in a mainframe language.

    Another factor is mainframe applications are often part of legacy codebases. When you’re dealing with code and dependencies that are decades old in some cases, you’re at a greater risk of ending up with software quality problems, despite your best efforts. Here again, detecting those problems earlier rather than later means they can be fixed without interrupting the entire CI/CD process.

    Finally—and most important—is the fact that in some cases, there is a large disconnect in terms of skill set and familiarity with mainframe code between software quality engineers and mainframe programmers.

    Your typical QA engineer today didn’t grow up with z/OS and may have limited experience troubleshooting software problems. Given the QA team is typically responsible for running pre-deployment tests, this can pose a problem in the event that QA detects issues with a mainframe application that it has no idea how to troubleshoot, let alone fix. By shifting testing to the left, it’s easier to give developers faster feedback so that they can fix bugs more quickly.

    How to Shift Mainframe Application Testing to the Left

    If you thought mainframes had nothing to gain from the shift-left testing movement, you might also think there aren’t many tools out there to help you do shift-left testing for mainframes.

    Fortunately, that’s not true at all. For unit testing, IBM offers Z Unit, a unit-testing tool for z/OS programs. Z Unit is included in Z Open Unit Test and IBM Developer for z Systems. Using these tools, Z developers can automatically generate unit tests for batch and CICS programs as part of their daily work. These tests can be stored in any standard SCM and can be executed independent of their environment.

    You can even test mainframe apps on non-mainframe hardware using Z Development and Test Environment. The platform creates virtual Z environments on x86 systems so developers can write, build and test their mainframe applications on any standard commodity server or development box.

    Conclusion

    Whether your mainframe applications are decades old or have been written from scratch in just the past few years, there’s nothing stopping you from taking advantage of shift-left testing to help validate them. Doing so will make it easier to achieve CI/CD effectively for your mainframe application, which keeps your software delivery team and your end-users alike happier by reducing bugs and delays.

    Check out the Z Open Unit Test demo.

    — Chris Tozzi

  • Why Did DevOps Become So Popular? 3 Theories

    Why Did DevOps Become So Popular? 3 Theories

    DevOps has now been a thing for a solid decade. As we look back at the history of DevOps, it’s worth asking: Where did DevOps come from, and why did it take off when it did?

    In honor of the 10-year anniversary of DevOps, I’d like to explore these questions.

    A Brief History of DevOps

    The very basic history of DevOps goes like this: First, there was agile, an idea exemplified in the Agile Manifesto that gained prominence among software developers in the early 2000s.

    Then, in 2008, Patrick Debois, a developer from Belgium, conceived of DevOps as a way to improve upon the agile concept by encouraging developers to work more closely with ITOps teams. His ideas began spreading in 2009. By the early 2010s, they had gained a sizable following and the rest is history.

    That, again, is a really basic history of DevOps. For more detail, I recommend this DevOps history post by Steve Mezak.

    Why DevOps? Why Now?

    The narrative of how DevOps originated is one thing. Explaining why DevOps became so popular in a relatively short span of time is another.

    As I see it, there are three possible theories to explain the rise of DevOps over the past decade. The first is to argue that Debois simply happened to have some very good ideas, and he promoted them well. You could think of this as the great man theory of DevOps’ origins. This seems to me, however, to be an unlikely explanation. It’s very rare for highly influential ideas to be born from just a single mind, or to spread through the singular efforts of one person.

    The second possible explanation for why DevOps became popular is it is simply an evolved form of agile. This is like arguing that World War II was simply a continuation of sorts of World War I, and therefore the origins of World War II are ultimately the same as those of World War I. From this viewpoint, the history of DevOps is really the history of agile, and so DevOps itself doesn’t have a unique history at all. I’d find this argument compelling if I believed DevOps is really just agile by another name, but I don’t. DevOps is broader, and has a much stronger implementational and practical element.

    The third theory—and the one I find most persuasive—is DevOps was born out of a particular moment in the history of computing and IT. That moment, which started in the mid-2000s, was marked by several key features that helped give rise to DevOps, including:

    • The widespread adoption, starting circa 2007, of cloud computing.
    • The success of the open source software movement around 2010 in making open source the go-to licensing strategy for many popular software projects and in making collaboration around code easier.
    • The rise beginning around 2010 of microservices and containers, which made applications much more complex to design, deploy and manage.
    • The explosive popularity of mobile computing starting with the launch of the iPhone in 2007. The mobile revolution meant organizations increasingly had to deliver software for multiple target environments (PCs, Android phones and iOS, for example) at the same time, necessitating branched delivery pipelines.
    • The demand for ever-increasing speed in software delivery as a way to gain an edge in software markets which, by the late 2000s, had grown more competitive than ever.

    When you put these changes together, you end up with a need to manage much more complex, fast-moving software delivery pipelines. Powered by cloud infrastructure and microservices architectures, the software market starting around 2010 required more responsive, better coordinated management by IT teams. DevOps provided an answer by increasing efficiency, decreasing response times and making software delivery faster.

    I don’t think DevOps would have taken off if the idea had emerged in the 1990s, when there was much less demand for fast software delivery, most applications ran locally and codebases were relatively simple.

    Nor am I sure DevOps would prove as popular if it were first introduced today. At present, we have a litany of management tools (such as Ansible and Kubernetes, to name a couple of examples) that didn’t exist 10 years ago. Those tools make it easier to handle all of the complexity of modern software environments even if you don’t have a management strategy rooted in DevOps culture.

    To put it simply, DevOps resulted from the combination of several specific developments in the world of IT between the mid- and late-2000s. Debois may certainly deserve credit for helping to spread the idea, but it would not have spread so quickly if it had not emerged at that particular time.

    — Chris Tozzi