Category: DevOps Practice

  • Predictions 2020: The Future of the Mobile Industry

    Predictions 2020: The Future of the Mobile Industry

    The mobile device industry continues to grow in leaps and bounds. Statistics show that, today, over 5 billion people have mobile devices and there are over 9.2 billion mobile connections worldwide. Add to these statistics the fact that the number of consumers who shop and bank online continues to grow as well–presenting hackers with increasing numbers of mobile applications and end-points to target. As developers of software that protect mobile apps from reverse engineering and hacking, at Guardsquare we have a unique purview into the mobility space, and therefore have some pertinent 2020 predictions for the mobile industry.

    Mobile Payments Apps on the Rise

    As consumers’ comfort with, and reliance on, personal technology increases, we expect to see purchases via mobile payment apps grow rapidly throughout 2020. Great news for the global economy, but the downside of this trend is it will serve to exacerbate opportunities for hackers to take advantage of mobile applications and devices that are not properly secured.

    Fake Apps Abound

    Fake apps or hidden apps have historically been a problem and we don’t see that changing any time soon. In December of last year alone, almost 65,000 new fake apps were detected among the various app stores, and we expect this to become increasingly common and problematic. Consumers need to be alert when downloading new apps and developers should be wary that fake apps can negatively affect their own reputation and their company’s. 

    Developers Beware Kotlin’s Hidden Vulnerabilities

    The new development language, Kotlin, is catching on now that it has been designated Google’s preferred language for Android development. However, many developers using the language still do not fully understand security best practices, including how to protect Kotlin code against OWASP’s well-known Mobile Top 10 risks. As with many apps written in Java, apps written using Kotlin must be protected against both static and dynamic attacks using a combination of code hardening and RASP.

    iOS Is Vulnerable Too

    We believe that 2020 will be the year in which awareness increases around the security shortfalls of iOS. Many application developers still believe iOS apps are virtually immune to reverse engineering, but, in reality, all iOS versions have already been jail-broken at some point.  We anticipate developers will take better security measures to ensure the integrity of their apps by employing a multi-layered approach to security to ensure the protection of their iOS applications.

    We continue to see the more sensitive an organization’s data, the more likely it is the mobile app will become a target for hackers. According to OWASP’s Mobile Top 10, reverse-engineering and tampering ranked the eighth and ninth most prevalent mobile security risks. Verizon’s Mobile Security Index 2019 highlights that more than 80% of organizations said they are at risk from mobile security threats, and 69% said those risks increased in the last year.

    It is our hope that, in 2020, all apps—but especially apps housing sensitive customer data—evolve from going unprotected to incorporating key security measures that protect the users and the organizations.

    Want to learn more about what to expect in 2020? Join us Jan. 23 for our Predict 2020 Virtual Summit  featuring discussions from some of the industry’s best and brightest offering up their visions for the future. Sign up today for this free daylong virtual event.

    — Roel Caers

  • Survey Sees More Complex API Challenges Ahead

    Survey Sees More Complex API Challenges Ahead

    A survey of more than 10,000 developers of application programming interfaces (APIs) suggests there’s lots of room for improving the overall efficiency of API lifecycle management.

    The survey was conducted by Postman, a provider of a platform for building APIs. Respondents on average said they only spend a quarter of their time (26%) on the development of APIs. The rest of the time is consumed by debugging and manual testing (22%), automated testing (11%), designing and mocking APIs (11%), managing others (9%), documentation (7%), monitoring (6%) and publishing (4%). A full 70% said they are spending more time on manual testing and debugging than they thought they should.

    All that time spent on manual testing and debugging may be having an adverse impact on the number of APIs that can be built, tested and deployed at a time when a transition to microservices-based architectures is requiring organizations to build and support more than ever.

    According to the survey results, about a quarter of respondents (24%) work with more than 20 APIs. Well over half those employed on average (53%) are for internal use, compared to 28% employed specifically for integration and 19% that are made public.

    In terms of technologies survey respondents are most excited about for the coming year, microservices (54%), containers (46%) and serverless computing frameworks (44%) top the list.

    As far as the performance is concerned, survey respondents are evenly split. Just under half (48%) said they feel that their APIs do not break, stop working or materially change specification often enough to matter. However, 28% said these issues arise on a monthly basis, while 16% said they deal with these issues weekly. Another 3% said it was a daily challenge.

    In terms of security, survey respondents are relatively confident: Nearly three-quarters of respondents (73%) said they feel that their APIs are “very secure” or have “above-average security.” Only 2% said they felt they were not at all secure.

    It’s hard to say how secure any API is without testing it. Rebecca Johnston-Gilbert, a marketing manager for Postman, said it’s apparent more organizations are starting to address security at the design phase rather than after the API has been built and deployed. Many organizations have already adopted an API-first approach to application development that enables them to manage them in isolation from the applications they are designed to support, she said.

    Among other survey findings, 73% of survey respondents said they work on a team of 10 members or less, while a quarter (26%) work on teams with 22 to 50 members. In addition, 78% of respondents have five or fewer years of experience in developing APIs.

    In general, survey respondents said they would like to see improvements in the areas of documentation (64%), standardization (59%) and sample code (58%), which suggests consuming APIs is still not all that simple.

    There is no doubt organizations increasingly will be applying best DevOps practices to the building and maintaining APIs. The challenge organizations face is, not only do they need to build and maintain what could soon be hundreds (if not thousands) of APIs to support microservices but also those APIs will need to be a lot more resilient as the dependencies between microservices exponentially increase.

    — Mike Vizard

  • The Top Six Cloud Computing Trends of 2019

    The Top Six Cloud Computing Trends of 2019

    Cloud computing was one of the hottest topics in the technology and business media throughout 2019. This is no surprise as the cloud sector has been growing rapidly for the last few years. Synergy Research Group recently reported a 37% overall growth year-over-year in public cloud. They also note that it has taken just two years for the public IaaS and PaaS markets to double in size and their forecast shows them doubling again within the next three years.

    While steady growth was expected this year, a few trends of note stand out. When the experts look back at 2019, they will likely stress the following cloud computing trends shaped the year.

    Rise of the Enterprise Cloud Manager

    We recently did a study on ParkMyCloud users which showed that a growing proportion of company technical leads have cloud or the name of their cloud provider–such as AWS–in their job title. This indicates a growing degree of specialization for individuals who manage and architect cloud infrastructure. Whether called enterprise cloud manager, cloud architect or something similar, 2019 saw the rise of a specialized role to oversee and direct cloud operations.

    Consolidated Multi-Cloud Views

    As enterprises large and small continue to adopt and use more than one public cloud, we have seen a rapidly growing need for a consolidated multi-cloud view and ability to take actions across multiple clouds in 2019. Third-party tools that do this provide enterprises the ability to pick a single tool to orchestrate, manage, govern and optimize their hybrid and multi-cloud environments. Many customers also sight the need to simplify operations—native cloud provider tools are not always easy to use.

    Multi-Cloud Arrives

    Multi-cloud truly arrived in 2019 and will only grow in 2020. The majority of organizations now use multiple clouds. In fact, most studies suggest that more than 80% of enterprises have a multi-cloud strategy. Reasons cited include the need to avoid vendor lock-in, the ability to leverage the best in class cloud services from each cloud provider and application efficiency choices.

    More Automation

    One of the biggest tech benefits to a DevOps approach is automating away the manual tasks that bog down operations and critical projects. Thus, the trend toward automation continued to expand in 2019.

    More Abstraction

    IT became more and more abstracted in 2019. This means container usage grew, along with models that allow developers to worry less and less about infrastructure (such as serverless and PaaS).

    Containers Became Mainstream

    Application containerization is more than just a new buzzword in cloud computing; it is changing the way in which resources are deployed into the cloud. More and more companies utilize container services such as Kubernetes and cloud native services such as EKS, AKS and GKS in 2019, 

    Business continued to move to the cloud in 2019 and the six trends described above showed that the sector is growing–sometimes in unpredictable ways. Next year will, no doubt, also contain some surprises. But the trend for expansion of the cloud and related services is unmistakable for the foreseeable future.

    — Jay Chapel

  • Predictions 2020: How to Make the Case for Adopting CI/CD in Your Organization

    Predictions 2020: How to Make the Case for Adopting CI/CD in Your Organization

    The practice of continuous integration and continuous delivery (CI/CD) is fundamental to modern software development. And yet, many organizations are still using slow, error-prone, manual processes to build, test and deploy their software. Sometimes, the blocker can be engineers who don’t want to change how they’ve always done things, but most often folks in the trenches are chomping at the bit to automate. All too frequently, it is IT leadership and executives who need to be convinced that making a large investment in updating tools, training and culture will net returns greater than the cost.

    If you want to change management’s mind about an investment in CI/CD, focus on making a strong business case. This may sound daunting, but it’s easier than you think. Learning a bit about how to advocate for budget and organizational change can go a long way. Just think about what life would be like if, instead of sitting in endless change management meetings, you could get your code to production simply by merging to master while automation takes care of the rest.

    This article will get you started with some concrete tips you can use to get CI/CD green-lit by your leadership.

    Start Small

    Agile and DevOps are all about breaking things up into smaller chunks. It may seem counterintuitive, but deploying more frequently equates to less risk because small changes are easier to orchestrate, troubleshoot and roll back than large complicated deployments. In that same way, you can reduce the risk to the organization by taking a DevOps approach to transformation. Rather than trying to upend your entire process, see how you can break the change up into small, iterative chunks.

    Almost every large enterprise that has successfully adopted wide-spread CI/CD started with one lighthouse team. Changing everything is a tough sell. Instead, approach management with a low-risk proposal: “We’d like to run an experiment to see if we can deliver more quickly and reduce costs. We have one team that will take one small project and test CI/CD automation to see what the results will be. We can leverage open source tooling to get started at a low cost.” Even the most stingy budget holder should find the proposal intriguing.

    Measure the Results

    Once you’ve started to conduct your experiment, it’s important to measure what you observe. What are the differences between the old way and the new way? The more concretely you can quantify it, the better. Saying, “We went faster,” doesn’t carry a lot of weight. But if you can quantify it, your message becomes more potent. For example, “Our previous cycle time from the moment a developer begins work on a ticket to the time that code is running in production and useable was 30 days. By automating some of our manual efforts using CI/CD we have cut that to five days.”

    For this part of the process there’s no need for exact numbers. Most likely if you aren’t doing CI/CD today, you likely don’t have the instrumentation in place to accurately measure cycle time. But don’t let that be a blocker. You can give estimates. “From about one month to one week,” is still a powerful story.

    Some other metrics to capture that can help make your case are:

    • Number of tests run.
    • Code coverage in terms of percentage of code tested.
    • Number of people-hours required.
    • Number of defects in production or number of regressions/roll backs needed.
    • Mean time to repair (MTTR): The average time from when a bug/failure is discovered in production to when the fix is running.
    • Frequency of releases—how often new capabilities are available for users.
    • Cost to deploy: This is a very powerful metric if you can estimate it. A good rule of thumb is: (number of people minus hours, times average hourly rate) plus (cost of assets and services required).

    Aim to use three to five metrics to prove your case. You don’t want to overwhelm with data. The point is to show that things are better with CI/CD, not that you’ve gathered a lot of numbers. Use a simple before-and-after format to show the change. State the changes in terms of increased value, reduced cost and/or reduced risk. For example, “We increased value for our users by shipping 10 times more features in the same time frame, reduced deployment costs by 80% and reduced risk by increasing code coverage by 30 points from 40% to 70%.” 

    Couple Your Efforts to Business Outcomes

    A critical element of IT success is how closely you can partner with the business. It can be next to impossible to get initiatives green-lit if the only benefit is to make things better for IT. But if you can show how some extra effort spent on IT modernization can drive results for the business, then you’ll find you start getting enthusiastic approval from leadership.

    Collaborating with people outside of IT or software R&D is a career-enhancing skill every technical practitioner should strive to improve. 

    Get to know what efforts in sales, marketing and product are dependent on IT. For example, the sales department may desperately need additional capabilities in their forecasting tool if they are going to execute strategic deal acceleration, ensure quarterly numbers are consistent and avoid unpredictability with shareholders. In other words, the fact that your slow delivery cycle can’t get those new features on the release calendar for another three months is putting the stock price in jeopardy.

    To avoid this tragedy, you can tie your CI/CD efforts to the sales outcomes. By getting to know the pain points of your sales colleagues, you can craft a powerhouse “ask” to leadership. “We’d like implement CI/CD to automate deployments for our sales data management system. This will allow us to implement new filters in a matter of days rather than months which sales needs to hit their numbers.” 

    Pulling It All Together 

    It can be demoralizing to feel like you are behind the curve. Looking at other businesses who have already adopted CI/CD it can feel like you might never catch up. If this is the case, some axioms are appropriate, such as the famous Chinese proverb from the Tao Te Ching “A journey of a thousand miles begins with a single step.” And as Theodore Roosevelt said, “Comparison is the thief of joy.”

    The reality is that you are not alone. Many organizations, especially large enterprises, are relying on outdated software practices. Convincing leadership to green-light IT modernization efforts can be a challenge. Adopting CI/CD in a meaningful way does require significant investment, but there is a lot you can do to smooth the path for them and earn their support.

    Begin by identifying a small adventurous team who can serve as an experimental testing grounds. Not only will their success help to convince leadership, but their example serves to light the way for other teams to adopt DevOps. Identify metrics you want to capture and be sure to instrument so you can measure the improvement. Pick a few metrics that show increase in value, decrease in cost and decrease in risk. Finally, reach across the org to collaborate with your non-engineering peers. By showing how your modernization effort drives outcomes for the business you’ll be sure to earn respect as well as additional budget to expand your CI/CD efforts.

    Want to learn more about what to expect in 2020? Join us Jan. 23 for our Predict 2020 Virtual Summit  featuring discussions from some of the industry’s best and brightest offering up their visions for the future. Sign up today for this free daylong virtual event.

    — William Chia

  • Untapping the Potential of DevOps, Part 3: Keys to Success

    Untapping the Potential of DevOps, Part 3: Keys to Success

    Over the course of this series, we’ve talked about some of the common mistakes we have seen organizations make as they either launch or continue their journey into the world of DevOps. But just as it is important to understand the pitfalls that may happen during a DevOps transformation, it is perhaps even more important to know what the key indicators are that drive success. With that in mind, here are a few tried-and-true tactics for making the most out of your DevOps initiatives.

    Start With Automation

    One of the most powerful areas of impact for DevOps is in driving automation. It accomplishes several things: it increases the velocity of the development pipeline, it can reduce the number of errors or potential errors in code and it often frees up time for developers, allowing them to focus more on creating value and less on repeatable and mundane tasks. By ensuring that DevOps automation goals, including CI/CD, test automation, monitoring, Infrastructure as Code and GitOps are included at the outset of projects, you can better set up your organization for successful software development and delivery—both in the short term and for the long haul.

    Strong Communication

    When it’s all boiled down, DevOps is like any other advanced business tactic as it relies on strong communication to deliver the most success. As the name implies, DevOps engineers must bridge the worlds of development and operations, so to be truly effective they need to possess fluency in both worlds. Can you have success if you have engineers who are only strong on one side of the equation? Technically, yes. But you will not maximize the amount of value from your DevOps initiatives without stakeholders who can adeptly manage both sides. Additionally, communication with the business and other non-technical sides of the organization is critical. The entire organization should be on board with DevOps, with clear visibility into the transformation—your successes and challenges will come from frequent, effective communication.

    Adhere to Processes

    DevOps is process-driven, particularly as organizations scale. To work effectively, and to serve real enterprise environments, creating and adhering to processes is key. While automation is important for the rapid delivery of value, effective change management is important for sustainable development and system operations. Process and compliance are an important part of sustainability for large environments. It is also extremely important for organizations where compliance is vital—think industries such as finance, medical and government. By implementing and adhering to well-defined processes, you can avoid future headaches or rework that will slow down the pipeline.

    Leadership Buy-in

    The most impactful changes have one thing in common: strong leadership. Leadership dedicated to delivering customer value and understanding the software’s prominent role in delivering that value is key. Organizations that cling to outdated methods of development and delivery (i.e. waterfall) lead to slower delivery of value, which is the ticket to extinction. DevOps also benefits greatly from having leaders within the organization who serve as champions for change. By keeping a finger on the pulse of your organization from within, you can better practice change management, identify potential weaknesses earlier on and make your DevOps initiatives work for you.

    DevOps can be an extremely effective way to deliver the most customer value from your software pipeline. By keeping these four key indicators in mind, you can better position your team for success and enjoy the benefits of your DevOps journey.

    — Jonathan Fries

  • An Overview of Cloud Migration and Open Source

    An Overview of Cloud Migration and Open Source

    Most businesses are moving toward making their business processes more user-friendly, through digitization. This shift of business modernization comes with a heavy price for them in terms of money and in terms of time. It is going to take time and a great amount of investment in new innovative technologies.

    Cloud computing is the biggest trend in digital transformation due to its ability to make business applications and infrastructure easily accessible. In the roadmap toward cloud migration, businesses are looking to save capital investment or expenses (CAPEX) and operational expenses (OPEX). 

    Open source technologies come to rescue for such businesses. Be those who are present at public cloud platforms such as AWS, Azure or Google Cloud, or private data centers. The role and emergence of open source technologies simplified the equation of overall expenditure for all enterprises and organizations of any industry domains. Year by year, more open source projects are coming up and solve major challenges which businesses are facing. Companies such as Red Hat and communities like Linux Foundation have a major role in promoting open source projects at the heart of digital transformation.

    Why Open Source at Cloud?

    • The main reason to adopt open source technologies in the process of cloud migration can be avoiding vendor lock-in in the future. Most public cloud vendors have a similar portfolio of open source supports in their offerings. As open-source projects are not owned by one company and its overall framework is common to all of its consumers, any updates to its core files have an impact on all projects. And businesses can simply move their application environment from one cloud to another without worrying about backend environment that is powered by open-source projects. There can be a seamless integration of applications and services developed or deployed by different businesses and vendors.
    • Open source adoption for cloud will help in interoperability with other enterprise solutions that can be located in different data centers. Though, other data centers should be equipped with the same open source projects. This interoperability enables the reuse of software stacks, libraries and components. Such interoperability can help deploy multi-cloud environment for businesses.

    The Cloud-Native Approach in Cloud

    Application containerization has been adopted by many solutions providers and vendors in the last few years and has become significantly popular. This containerization surge has triggered the use of cloud-native applications. Most of the popular cloud-native projects are hosted in Linux Foundation’s CNCF (Cloud Native Foundation) community which nurtures the development of various open source projects. Some of the popular projects are Kubernetes, Prometheus, Envoy, Helm, rkt, Linkerd, Etcd, Jaeger, etc.

    The cloud-native approach involves the utilization of tools for handling containers, micro-services, service mesh, DevOps and continuous integration (CI) and continuous deployment (CD). Cloud-native tools for CI/CD can be Check, Ansible, puppet, etc., and service mesh can be Istio, Linkerd, etc.

    Most of the enterprises tend to involve open source projects from various umbrella’s to build the Cloud migration strategy. Moving to cloud-native management of application can be a prominent requirement for many enterprises.   

    Open Source Cloud Migration Tools

    There are open source tools and frameworks that help with cloud data migration. These tools require modification in terms of coding to make the migration process that suits your infrastructure. To make coding customizations in these tools you might need investment for skilled resources.

    The above projects help enterprises to move data. Bluethroat is an open source project which can be used for migration of overall infrastructure from data center to data center, data center to the cloud, cloud to data center and cloud to cloud. Currently it is powered with limited features and used specifically for AWS. It offers the following features:

    • Migration of infrastructure to AWS.
    • Agentless.
    • Environment discovery.
    • Automatic network creation and server deployment.
    • Linux server migration.

    Conclusion

    Cloud migration has its own challenges in terms of uptime, security and data loss. Most public clouds are evolved to handle data as well as application workload migrations. There are many benefits to open source projects, as discussed in this article. The main advantages of migrating open source frameworks to the cloud are cutting back on expenses and avoiding bottlenecks.

    — Sagar Nangare

  • Infrastructure as Code and Six Key Automation Concepts

    Infrastructure as Code and Six Key Automation Concepts

    This summer, I walked into an Infrastructure as Code (IaC) flame war because I was blissfully unaware of just how broadly IaC had been reinterpreted. Reviewing the comments, it’s clear that thinking has evolved since Kief Morris’ 2016 Infrastructure as Code tomb. So, after strapping on my asbestos suit, I decided to dig into what is creating such a wide range of opinions and see if I can share some 2019 insights.

    Why does IaC provoke such passion? The reason is simple: As an industry, we aspire to something that delivers on our collective vision of fully-automated, self-governing infrastructure. In the 00s we called it autonomic computing, then software defined data center (SDDC) and, now, IaC. Sadly, IaC is not it—or, more specifically, it’s not it alone.

    The actual definition of IaC is way smaller than what people want it to be.

    My take-away from IaC discussions is they are built around six key automation themes. Let’s take a few minutes to examine each of the themes. Then we’ll have a basis for answering “If that’s not IaC, then what is it?”

    Programmatic Configuration (IaC)

    Programmatic configuration captures the idea that we can define our infrastructure in a machine readable format. For example, you describe a planned cluster build in YAML to execution by a tool such as Terraform that requests the resources from your dynamic infrastructure and, hopefully, tracks that resource descriptors you get back from that request. Basically, it’s just your IaaS input format.

    Dynamic Infrastructure (or IaaS)

    It describes a system that allows operators to change the resource allocations via an API. It’s a critical part of the discussion because there must be a dependable way to pragmatically change the infrastructure. Some would consider this cloud; however, we should not assumes either managed services or VMs because dynamic infrastructure is much broader.

    Desired State (or State Reconciler)

    Desired state actively compares dynamic infrastructure to programmatic manifest and makes automatic adjustments to keep them synchronized. Typically, the idea of maintaining state is separated from configuring systems. Kubernetes and other Autoscaling cluster managers perform this role.

    Deployment from Source Control (or Immutability)

    It implies that all of the configuration components of the system can be stored as versioned artifacts and deployed from source. A Dockerfile that builds a container is a good example of an immutable process and the generated artifact. The repeatability offered by deploying from source control is transformative compared to past generations of operations that relied on either manual or scripted changes to production systems. Immutability is not IaC: We are focused on an generated deployment artifact rather than managing the infrastructure.

    Composable (or Modular) Automation

    It allows us to manage complex structures through layers of abstraction. In concept, composability is as simple as using platform plugin to script against an API.

    CI/CD Pipeline

    CI/CD pipeline is the glue that pulls all these pieces together to create a resilient environment by continuously adjusting the system components based on the operators’ IaC descriptions. The pipeline relies on having dynamic infrastructure managed to desired state as a target; however, it adds the critical concepts of staged changes over time to the system. Since we need to create systems that can adapt and improve over time, the CI/CD pipeline provides mechanism for controlled implementation change over time.

    Together, these six concepts reflect an integrated new way to think about the infrastructure that is beyond IaC. They allow us to maintain and control our systems over time in a way that is resilient and automatic. More importantly, they bring complex infrastructure problems back into terms that people can comprehend by creating more deterministic and predictable chains of change. That allows us to keep our hands out of the infrastructure and our minds focused on what we are delivering: a continuously integrated data center.

    Since all six concepts are interdependent, continuously integrated data center (CI DC) completely captures our aspirations for IaC. The term intuitively builds from source code into a fully operational infrastructure. More importantly, CI DC demands that we acknowledge the ongoing maintenance required. For that reason, I’ve embraced CI DC to replace IaC.

    Does the term work for you? How do you see IaC or CI DC being delivered in 2020? I’d like to hear your thoughts.

    — Rob Hirschfeld

  • Why Is Security Missing in Many DevOps Implementations?

    Why Is Security Missing in Many DevOps Implementations?

    The exceptional and ground-breaking, technology-driven opportunities in today’s digitized age come with significant competitive pressures to transform promptly. Specific demands increase due to continuous repeating in response to customer preferences becomes the more deep-seated expectation. To overcome this issue, organizations are shifting toward DevOps as a medium to deliver innovations quickly.

    DevOps also promotes innovation and agile software development but, for optimal results, proper security implementation is required. When business security teams are more cohesive in the development culture it is easier to secure new developments from the start. 

    DevOps is all related to automation and speed. At times this can make the apps in development get exposed to malicious attacks, which results in various scams. However, the end customer is seriously concerned about the security feature. The tools you’re going to choose might be vulnerable to different security issues. Hence, it is essential to select those tools that comply with security concerns, such as the General Data Protection Regulation (GDPR).

    DevOps culture is driven by moving fast yet in small pieces. It offers organizations with a wide range of benefits, which includes cooperation among stakeholders, development processes, improvements in code quality, as well as enhanced business velocity. 

    DevOps is responsible for solving different challenges in the software development process, but at the same time, it also familiarizes new challenges. It is found that less than 46% of IT experts are neglecting security in DevOps design and planning. Such environments end up with an inactive and uncoordinated approach to incident management and mitigation.

    There are several reasons for security being missed during DevOps implementation. Some of them are discussed below.

    Cultural Resistance to Security

    It is a standard view in many organizations that introducing security will lead to a slower development process. However, the overall effort and time cost of catching some security flaws early in the design or development process is much lower than to fix the problematic code and weaknesses later during the development cycle. 

    More Focus on Speed Than Security Teams

    DevOps teams are often associated with InfoSec teams. DevOps induces and modifies code batches over a short period, which might far outpace the speed at which the security teams can keep up with code review. If security—code analysis, configuration checks and vulnerability scanning—is not adequately automated, the DevOps output will eventually be slowed down or result in a lack of security hygiene. 

    Practically, this fallout consists of insecure codes, inadvertent vulnerabilities, hard-coded passwords, misconfigurations and other weakness in-app security that can contribute to operational dysfunction or get exploited by attackers.

    DevOps and Cloud Environment

    A typical DevOps environment is dependent upon cloud deployments, which often shares many cloud security considerations. DevOps teams influence the latest, open-source and even immature tools to manage various security groups and server instances. In this digital age that function at large scale, a slight misconfiguration error or security malpractice can be widely propagated, resulting in extensive operational dysfunction or other exploitable compliance and security issues.

    Poorly Managed Access Controls

    Most of the aspects of DevOps are interconnected, changing rapidly and utilizing secrets. DevOps secrets might include private account credentials, APIs token, SSH Keys, etc. that might be used by both humans and non-humans, for example, apps, containers, cloud instances and microservices. Ineffective secrets management is a common flaw in DevOps environments. It provides a provoking possibility for attackers to interfere with the security and other controls, disrupts functions, steals information and exploit an organization’s IT infrastructure. 

    Moreover, to further advance the workflows, DevOps teams might also allow unrestricted access to some private accounts by multiple individuals, who might share their credentials. This is a practice that eliminates the chances of a clear audit trail. Several methods, configuration management, as well as other DevOps tools, might be granted immense privileges. With access to private accounts, an attacker or even a piece of malware can get full control of the data and systems.

    Security should be a top priority of an organization while implementing DevOps, but due to the practices mentioned above it is often neglected.

    How to Ensure Security in DevOps?

    Sticking to security helps the team to come up with quality code. This practice makes developers write error-free codes. When this culture turns into a norm, it fosters the DevOps efforts as a whole. Below are some of the ways to ensure security in DevOps:

    • Set a priority list and put things according to it. Shift the security focus to the left in the development lifecycle.
    • Ensure that developers are well aware of the security consequences and principles and follow the same path as of yours.
    • Educate and train your developers to use particular tools to build secure systems, as well as also keep your DevOps system safe.
    • Set up an alerting and monitoring system to avoid any damage in the end. 
    • Do have proper metrics and submit reports daily to ensure that everything is under control.
    • Various compliance tools and the best business security systems should be introduced into the toolchains. If the codes fail to pass security tests, the build breaks and does not gets deployed so, sent it back to the developer for further refining.
    • Adopt different configuration managements. It means do scans to identify and remediate possible errors. Stabilize all configurations by using the industry’s best practices. Also, allow continuous configuration and hardening baseline scanning across various servers and codes which are built for cloud assets.
    • Do prioritize the deployment of automated tools to detect possible threats, problematic or vulnerable codes and other issues with process and infrastructure. More strictly, you will match the speed of security to the DevOps process; the less you’re going to come across culture resistance, which is embedded in the security practices.
    • Shift toward the rising trend of DevSecOps. It is a practice of injecting security in the lifecycle of app development. It reduces vulnerabilities and brings security much closer to business goals.

    Final Thoughts

    Security is a crucial element in DevOps implementation because it influences the bottom line of any organization. At times, security is missed out, but if this continues it will eventually lead to exploitation by hackers and loss in customer trust. Remember, everything can be recovered, but once a customer’s trust is lost, it can never be gained again. Thus, it is imperative to ensure security while implementing DevOps and achieve success by leaps and bounds.

    — Farwa Sajjad

  • Testing Emerges as DevOps Hurdle in Mainframe Shops

    Testing Emerges as DevOps Hurdle in Mainframe Shops

    A survey of 400 senior IT leaders responsible for application development using mainframes finds 90% believe automating more test cases could be the most important factor in their success, as the pressure to accelerate innovation increases. However, the same survey finds only 7% of organizations automate the execution of test cases involving mainframe code today.

    The survey, which was conducted by Vanson Bourne on behalf of Compuware, also finds the time required to conduct thorough testing is the biggest barrier to integrating the mainframe into agile and DevOps processes for just over the half the survey respondents (53%), followed by a lack of skills (39%) and lack of understanding how code changes will impact distributed applications (34%).

    A total of 82% said that unless they can automate more test cases, they will not be able to meet the need for speed the business now requires. That may account, in part, for why 56% of respondents said they plan to start automating the execution of test cases on mainframe code within the coming year.

    The biggest benefits expected to be derived from those investments include greater efficiency within the IT team (59%), improved consistency of testing (53% ), reduced chance of human error (47%), reduced pressure on IT teams (47%), accelerated innovation cycles (46%) and less chance of bugs making it into production (40%).

    Primary areas of focus for automated testing are ranked as functional testing (63%), followed by integration testing (53%) and unit testing (37%).

    The survey also finds development teams are spending, on average, more than half their time (51%) on testing during the release of a new mainframe application, feature or function. That compares to 39% of their time testing applications, features or functions on applications that don’t run on mainframes.

    A full 92% said mainframe teams are spending more time testing code than they needed to in the past because of the growing complexity of cross-platform application environments. Issues organizations are contending with are “Manual and time-consuming test processes” (44%), “Mainframe testing processes require specialists that are not always readily available” (40%), “Testing processes are costly” (39%) and “It’s hard to visualize and understand dependencies” (35%).

    Not surprisingly, 77% of respondents find it increasingly difficult to simultaneously increase quality, velocity and efficiency to meet business innovation goals when developing and testing mainframe application code. Top concerns when it comes to mainframe development are introduction of security flaws (50%), impact on customer experience (38%) and disruption to operations (36%).

    A full 85% said it is becoming more difficult to deliver innovative and faster applications without compromising quality or increasing the risk of bugs finding their way into production.

    Steen Brahe, product manager at Compuware, said organizations that have mainframes are usually under pressure to innovate faster now because competition from startups relying on DevOps processes and modern platforms has increased sharply. Rather than incurring the cost of replacing mainframe applications on which the business currently depends, organizations that have mainframes are looking to extend DevOps processes to integrate emerging and legacy applications.

    It’s not clear to what degree those organizations will succeed. However, the one thing that is clear is organizations with mainframes that fail to embrace best DevOps processes are already most certainly doomed.

    — Mike Vizard

  • Emerging Patterns in SRE Implementation

    Emerging Patterns in SRE Implementation

    First we were told that every company will become a technology company. Then the tides shifted to every company will become a DevOps company. Now the zeitgeist has a new obsession: Every company will become a Site Reliability Engineering (SRE) company.

    Have you been keeping pace? If your company survived the ruthless restructuring of digital transformation and is savvy enough to have surfed the DevOps wave, you might already have heard SRE is the next industry standard on the horizon. And you might be bracing yourself for yet another cycle of emerging best practices. Is the dread setting in?

    Fear not, throwing out the welcome mat for SRE does not require kicking DevOps to the curb. On the contrary, the two are complementary philosophies, which, when harnessed correctly, can usher in a new era of value delivery. Essentially, SRE is a specific implementation of the core DevOps pillars of success that applies a software engineering mindset toward solving traditional operations problems–with a focus on creating reliable and scalable technology. Together, DevOps and SRE work in harmony, striving toward a shared goal of breaking down organizational barriers and delivering better software faster. 

    If you’re ready to give SRE a shot but you are unsure how it best fits within your team’s existing structure, let’s break down the top five team organizational structures that emerge with clients. However, feel free to view these as loose guidelines rather than an exact blueprint. Similar to DevOps, there are diverging views and practices of integrating SRE into a company’s structure.

    Discovering the unique way SRE fits into your team is the most rewarding and fun part of adopting this new system. What matters most here are outcomes. Creating a role for SRE means alleviating some of the pressure on your developers, allowing them to be more productive, and more efficiently and effectively implement the DevOps paradigm. Soon enough you’ll be reaping the benefits of what happens when, as Ben Treynor, Google vice president of engineering said, “a software engineer is tasked with what used to be called operations.”

    The OG(oogle)

    Let’s give credit where it’s due. We wouldn’t have the SRE acronym, let alone the entire discipline, if it weren’t for Google’s innovative ops team. With the aim of bridging the gap between its production and ops teams, Google ops leader, Ben Treynor proposed eschewing the norm of building an ops team solely from system administrators and instead bringing in software engineers who possessed a systems background.

    This model entails creating a dedicated engineering team focused on running and scaling a product or platform. The team should be comprised of highly skilled software and systems engineers who are on-call for the product, and simultaneously directly updating the product code base for reliability and building associated tooling to support the product. Most importantly, the product development team is still responsible for a portion of these operational tasks and may not be allowed to ship new features if reliability falls below agreed upon thresholds (the Error Budget).

    Why Change When You Can Rebrand?

    If your ops, DevOps and platform teams are on board with the SRE philosophy but you either don’t want or don’t need to make significant changes to your product code, this is the approach for you. In this model, your teams can simply rebrand as Site Reliability Engineers, while adopting and implementing the tenets that come with the title. That means shifting the concentration of engineering to focus on improving reliability and scalability. This team would also be on-call, playing a prominent role in the underlying infrastructure, tooling, platforms or day to day support of the product.

    Beware: You need to take seriously the underlying tenets and need for strong software engineering skills on these teams in order to realize the benefits.

    The Inside Job

    Perhaps you’re down with SRE but don’t want it to co-mingle with product accountability. A viable option then would be creating an internal consulting arm–a centralized team solely dedicated to creating and advocating for reliability tools and processes. One of the prominent benefits of this structure is that your team would be able to not only see the forest for the trees but also serve as your SRE gurus, keeping your team abreast of the latest technologies, trends and research in the SRE space. 

    You Get an SRE Engineer!

    For those who want to weave in SRE engineers throughout their entire organization, this approach applies a holistic mindset to the SRE implementation proposition. That means SRE engineers are introduced into cross-functional teams that own the end-to-end lifecycle of a product, from build through decommissioning. From here the road diverges: your choice is to either create an SRE team of engineers who belong to a single capability and are also embedded full time within a product team, or allow product teams to hire their own dedicated SRE engineers. As Cloud and SRE Practice Lead at Slalom Build, I took the former. For us, this approach guarantees bespoke SRE implementation, ensuring right-sized scalability and reliability throughout the product lifecycle.

    SRE? New to Me

    Despite the compounding hype around SRE, it has yet to hit universal name-recognition. If it’s still unfamiliar to you, that’s okay. It’s not too late to raise your hand and get up to speed during this period in which we are still in the early stages of adoption. I assure you that if you reach out to expand your knowledge of SRE and even bring it back to your team, you will be met with enthusiasm and welcoming arms.

    — Rob Cummings