devopsy.kinsta.cloud

Category: DevOps Practice

  • Accelerating MVP Development Performance Through DevOps

    Accelerating MVP Development Performance Through DevOps

    The core concept of minimum viable product (MVP) is to get maximum learning and understanding regarding what customers want about a product. Learning and understanding is a continuous process requiring a development process that is incremental in nature. That makes DevOps a favorite for CIOs and everyone else who dabbles with MVP development.

    How can DevOps help in accelerating MVP development?

    Continuous Updates

    Any MVP is built with assumptions about customer preferences in mind. Developers may have a deep understanding of what customers want, but they have no solid proof. The MVP “tests the waters” and measures the depth of the customer reaction. Developers then can develop and refine the application further, depending on the customer responses.

    Building an MVP that can be easily updated is no easy task, however, especially if the MVP juggles too many APIs that collect data from heavy databases. Traditional application development tactics may not work here. It is here that DevOps makes a difference. Its continuous integration and continuous delivery (CICD) tools ensure that any application or MVP can be easily updated according to dynamically changing scenarios.

    In other words, DevOps can help accelerate MVP development.

    Microservices

    Microservices is a concept in DevOps where the application is broken down into several loosely held parts. For instance, when a social media app is being built, its various components such as a newsfeed, stories, chabot, etc., are built separately as microservices.

    The prime benefit of microservices is that the updating, maintenance and bug-fixing process is simplified and easy to manage. For MVP, this translates into easier editing of feature sets to meet changing customer preferences. Also, it breeds an organizational culture of collaboration in which developers as well as applications have to mingle with each other to perform better. Such a collaborative environment is key to accelerated development of MVP.

    Extensive Automation

    DevOps and automation go hand in hand. In fact, zero-touch automation is deemed to be the future of DevOps. Right from continuous business planning to feedback optimization, there is plenty of scope in MVP for automation.

    Needless to say, automation drives operational agility. It also quickens the pace at which routine tasks are done. DevOps adoption for MVP development means developers can make more features and deployments faster within a short span of time.

    A Scalable Foundation

    Infrastructure as code, or IAC, is a key DevOps practice. It works by configuring servers automatically, especially cloud-based servers. IAC works by creating a single configuration file for all the servers. It is like a single template of configuration that can be cloned easily for several servers.

    As a result, DevOps allows applications to quickly ramp up their server capacity in a flash. The same goes for MVP: When the MVP gets the nod of consent and is mature for advanced development, the same server setup can be used as a foundation for upscaling the resources. Also, the same configuration file can be used to set up as many as servers as you want. What is the result? Cloud servers up and ready to use without loss of time.

    DevOps and MVP Development — A Formidable Combination

    Deploying a MVP is an integral part of the development process. DevOps, with its microservices and IAC approach, can help accelerate the pace at which applications are developed and deployed. Additionally, CI/CD tools ensure wide-scale collaboration among teams.

    Integrating a DevOps culture right from the MVP stage of an application will help in the development of a final product that is bespoke to customer requirements. Even if the customer requirements are different, microservices help to quickly modify them and update the application without significant downtime. To sum it up, DevOps is the perfect approach to accelerate MVP development.

    — Dhaval Sarvaiya

  • VR Development Guide: Choosing the Right Engine

    VR Development Guide: Choosing the Right Engine

    Creating virtual 3D worlds has been a dream of programmers for many decades. Virtual reality, once a faraway fiction, is becoming a reality. Failures such as Nintendo’s infamous Virtual Boy are now a distant memory, and major successes including PSVR and Google Cardboard have become the norm for the emerging technology. In fact, Statista projects incredible growth for virtual reality, estimating that the market will expand to $40 billion by 2020.

    Creating Your Own VR Apps is Possible

    Creating your own virtual reality applications is more possible now than ever. The cost to participate in virtual reality, for both consumers and developers, has lowered dramatically in recent years, and a plethora of tools is now available for new development teams to enter the fray.

    One of the most important elements to your virtual reality development process is the engine you use to build with. Unless you have unlimited time and unlimited resources, it’s in your best interest to use a commercial engine rather than create one yourself.

    Developing VR Apps with Premium Engines

    Akin to other development environments, there are many free-to-use and open source engines at your disposal. You’ll have plenty of options to choose from, but you’ll need to educate yourself about these tools to ensure you’re making the best project in regard to your specifications.

    The Unreal Engine and Unity have been used for myriad 3D video games and virtual reality applications. They have been classic choices for video game development and even for mobile app development.

    The Unreal Engine is free to use and allows development teams to create their own interactive applications at no cost. Once your application is developed, however, you’ll have to share a small percentage of your profits with the Unreal team.

    How to Build VR Apps Without Coding

    Interestingly, you can code your entire application with simple logic alone through the use of their Blueprint Visual Scripting functionality. With Blueprints, you can design programmatic actions, methods and computer behavior without writing a single line of code.

    This design feature isn’t available on any other major engine. If you have a design-heavy team, filled with more analytical designers and artists than programmers, you may want to consider using the Unreal Engine.

    Why Unity is a Developer Favorite

    Unity, a similar engine yet underpowered when compared to Unreal, allows developers to use their engine for a small upfront fee, but you won’t have to pay out any royalties once you’ve purchased the program. To use Unity, you’ll need to have a team with strong C# skills.

    If you don’t have a strong background in C# and don’t have the funds to bring on a more experienced C# programmer, you should strongly consider using the Unreal Engine. If your team has the programming ability and design ability, Unity can be a great and relatively low-cost option that sacrifices little in terms of quality.

    There are Great Open Source Options, Too

    If you’re looking for the lowest cost possible, you’ll want to investigate completely free engines. Video game engines such as Godot may be serviceable, but virtual reality compatibility is not completely assured. You’ll have to devote more time and resources into editing the engine your needs.

    Completely open source virtual reality-ready engines are also available for use. Apertus VR is one such example. It’s a set of embeddable libraries that can easily be inserted into existing projects. OSVR is another virtual reality framework that can help you begin developing your own virtual reality games. Both OSVR and Apertus VR are fairly new creations, however, and you may experience bugs and other issues you would not encounter with Unity or Unreal.

    Conclusion

    Developing virtual reality applications is incredibly hard work, but with a bit of persistence and with some help from experienced developers, you should be able to get the hang of the virtual reality development process.

    While you can’t control a great deal of what happens within the development process itself, you should make absolutely sure that your framework is well laid out.

    Selecting an engine or virtual reality framework that works for your team is a decision that requires a great deal of time and effort. Take your time weighing the pros and cons of the tools available to you. Moving forward will mean you’re committing yourself and your team to a specific engine. That sort of decision has a lot of weight in the development process.

    — Anthony Coggine

  • How to Automate HIPAA Compliance with DevOps

    How to Automate HIPAA Compliance with DevOps

    DevOps can help make HIPAA compliance more achievable

    Automating the provisioning of HIPAA-compliant server infrastructure enables compliant hosting service providers with the ability to provision and deploy infrastructure-as-code with minimal human intervention. Providing the automated process is thoroughly tested, revised and updated, it can offer a healthcare organization huge flexibility when enforcing a HIPAA-compliant server or serverless infrastructure within a private, hybrid or public cloud offering.

    Organizations that practice centralized operations, also known as DevOps, have a unique team who have the desirable skills of software development, IT operations and quality assurance (QA). The DevOps objective is to create a performance-based IT solution within a greatly reduced provisioning lead time using technical server blueprints within a continuous delivery environment.

    DevOps within a healthcare organization must be able to meet the stringent administrative, physical and technical safeguards required by HIPAA. In all cases, the required safeguards must be met, but with DevOps, it can be significantly easier to meet the addressable requirements of HIPAA.

    Planning

    Each healthcare organization can present differing business needs which they need a HIPAA-compliant service provider to resolve. It is not always possible to provide a cookie-cutter solution for every healthcare organization, often one design does not fit all; however, it is possible to create a baseline of operations using automation.

    A great deal of planning must be completed with all relevant stakeholders to not only understand the technical solution but to gather critical information about unique aspects of the architecture and then plan ways to automate the delivery process.

    It may not be possible to automate every workstream, but getting the DevOps team involved in the early planning stage will allow thorough and accurate playbooks to be created.

    With advanced planning, significant gains can be made in defining the networking security layout for the healthcare clients virtual private cloud, work out what isolated cloud resources can be defined and make decisions about potentially leveraging network layer protection services such as DDOS protection or a software-defined web application firewall.

    Provisioning

    The next step to creating the infrastructure-as-code is to write the automation playbooks that will provide the infrastructure. There are several provisioning applications that can be used, such as Terraform, Chef, Puppet, Google Deployment manager or AWS Cloud Formation, and playbooks will need to be written (or converted to) a compatible language such a python, YAML or JSON.

    The machine-readable code interacts with the service provider’s API front end; this may be an on-premises VMware vSphere cluster or a public cloud provider such as AWS, GCP or Azure. The API interprets the code and uses the descriptor commands to provision and deploy infrastructure in a cloud environment.

    A DevOps engineer will select the cloud provider they using and then define all the environmental variables to use to create the infrastructure-as-code. Connection variables are usually configured first and will define the cloud provider locations, regions and availability zones, as well as the encrypted account passwords or IAM configuration to interact with the provider API.

    Once the connection variables have been initiated with the provisioning software of your choice, they are used throughout the project life cycle. The next stage is to define the HIPAA infrastructure environment, including storage, network and compute resources. This will include provisioning resources and setting private and public networking.

    At all stages of the design it important to define where ePHI data will be stored and processed. The process must include step-by-step documentation and a customer responsibility matrix. At this stage, it is imperative to incorporate technical safeguards such as server access control lists (groups), introduce activity logging and provide auditable controls.

    Server hardening policies must be created for servers, active directory, workstations or providing least privilege authorization accounts at multiple levels, such as user profiles, that enable or restrict access to individuals or third-party systems. Preapproved software is typically installed at this step as well.

    Next, the inclusion of boot volume encryption and encryption of disk objects and storage volumes must be defined, this is easily achievable on mass provisioning of servers, simply providing a volume ID and an encrypted $TRUE statement.

    Throughout the playbook designing phase, testing is conducted to close loopholes, refine automated network configuration and create shared VPN tunnels with passwords that automatically cycle. The playbooks set the properties which make an organization HIPAA-compliant, and can also be used to create secured bastion servers if VPN is not an option.

    Playbooks allow DevOps teams to create rotating security keys, SSL certs and log aggregation and filtering. This can also be configured to trigger automated messages that can be emailed in case of any errors or failures in the automation process.

    Continuous Delivery

    When all the playbooks are streamlined and accurate, they can be used to define a healthcare clients service catalog, which enables the use of standardized templates to be used within the HIPAA environment. This may include server templates, container configuration, storage templates or any predefined software application.

    Security tools can be used to track and inventory resource usage and any system changes, track all user activity and any API activity requests.

    Monitoring tools can be used such as Cloud Watch, Nagios or Nimsoft to monitor server resources and application usage, these monitoring tools can also pick up errors or predictive errors and alert against predefined thresholds.

    Many organizations choose to use serverless workloads such as Docker or Kubernetes. These massively scalable solutions also bring about a huge benefit that aids the DevOps continuous delivery approach of automated update rollouts—essentially, applications can be isolated over differing pods, allowing the underlying hardware to be updated or versioned with zero downtime.

    DevOps is changing the automated delivery of HIPAA-compliant solutions. It is important to remember that DevOps does not have all the answers for HIPAA, especially many of the administrative regulation. However, it does empower managed service providers with the ability to provide tried and tested automated solutions that meet or exceed the technical and physical safeguards of HIPAA compliance.

    — Moazzam Adnan Raja

  • Survey Sees Need for More Consistent Approaches to DevOps

    Survey Sees Need for More Consistent Approaches to DevOps

    DevOps is arguably one of the most disruptive forces driving transformation of IT processes in recent memory. But a new survey finds that while IT organizations are making progress, adoption of DevOps processes remains uneven at best.

    A survey of 2,419 IT professionals conducted by OverOps, a provider of code analysis tools, finds that 82 percent of organizations have partially adopted DevOps practices, while only 17 percent of respondents claim to have fully adopted DevOps. Obviously, not every workload requires an organization to embrace DevOps processes to manage it.

    But OverOps CTO Tal Weiss said the survey shows that as organizations increase the rate at which application workloads are being deployed, a fair amount of chaos is starting to reign. According to the results, more than 90 percent of companies deploy code at least once a month, and more than 60 percent release code at least once every two weeks. Nearly 40 percent, however, indicate that moving too quickly is a primary reason errors make it into production.

    Worse yet, more than 50 percent say they rely on customers to tell them about errors in production, even though 60 percent of respondents say they use automated tooling for error notification and to ensure application quality.

    Not surprisingly, IT teams are still spending an inordinate amount of time troubleshooting their environments. More than a quarter of respondents say they still spend at least roughly one full workday per week troubleshooting errors. Another 42 percent of respondents spend 10 percent to 20 percent of their time troubleshooting.

    The good news is that IT is increasingly being viewed as a team sport. A full 67 percent of respondents believe their entire team is to blame when an application breaks or has an error, and 73 percent said both developers and operations are equally accountable for ensuring the overall quality of an application.

    Weiss said more organizations need to implement a more structured approach to DevOps based around the same continuous integration/continuous deployment (CI/CD) platform. Too many organizations today are adopting DevOps processes from the bottom up when it’s become clear that top-down initiatives for driving consistent adoption of best DevOps practices are now required. One of the biggest challenges facing IT leaders, however, is identifying and implementing the metrics that will be employed to identify those best practices, he said.

    Change, of course, comes hard to any IT organization. It may take IT organizations years after acquiring new tools to define their processes. Inertia surrounding existing waterfall and ITIL-based processes can be incredibly high. But as the amount of software that needs to be deployed and updated continues to increase, risk levels associated with deploying applications also are starting to increase. Many organizations are now essentially experimenting on their end customers. How much tolerance customers have for trial-and-error approaches to applications development and deployment remains to be seen. In the meantime, IT organizations would be well-advised to resolve to do DevOps better in 2019.

    — Mike Vizard

  • Building Amazing Apps, Part 1: Optimizing the Front End

    Building Amazing Apps, Part 1: Optimizing the Front End

    There are millions of apps available today, and it’s incredibly easy for any user to download and install any of them with just a few taps on a screen or click of a mouse. If you want to build and deliver an app that will amaze users, you need to be able to differentiate from the rest of the pack.

    Over the past 14 years, I’ve been working closely with the top companies delivering the most popular apps, helping them optimize their apps for speed and scale so users get a great experience. In this three-part series, we’ll explore the fundamental steps you must take to build and deliver your own amazing app at scale that will keep users coming back for more.

    We’ll break these steps down into three key areas:

    • Front end: Covers the parts of the app that end users interact with.
    • Back end: Looks at the required origin infrastructure to support the app, including databases, application, web servers and more.
    • Middle-mile: Explores the internet, where all the information needs to traverse back and forth between the front end and back end.

    Let’s explore the front end, and the five things you need to take into consideration to build and deliver a world-class front end for an amazing app.

    Beautiful User Interface

    People love beautiful things. That’s why they enjoy looking at the orange colors of a sunset or why they pay exorbitant amounts of money for a work of art. Building an aesthetically pleasing interface must be a top priority during the design phase. The first sign of a good user experience is an attractive design, and users are more likely to spend more time with the app if it is appealing to the eye.

    So where do you start when designing your app? Begin by reviewing the most popular apps on the app stores or the ones you use and enjoy the most and write down what design characteristics you like from each one. You should also follow industry best practices for app design such as:

    • Pay attention to graphic design.
    • Ensure you use curated images that look great.
    • Pick beautiful fonts with curved edges, e.g., Open Sans.
    • Manage white space effectively to display as much information as possible without having crowded text.
    • Ensure your UI is intuitive and simple to reduce the learning curve.
    • Avoid information overload through short and clear wording.
    • Maintain consistency within all the screens in the UI.
    • Select a distraction-free UI that avoids blinking text and excessive use of colors.
    • Follow standards (follow UI designs already in place).

    Accessibility

    At a fundamental level, it is a social responsibility to ensure your application can be used by people with impaired mobility, vision, hearing, cognition or language understanding. In some context, it is also a legal requirement.

    An excellent accessibility reference for developers is the Web Content Accessibility Guidelines (WCAG), which is sponsored by the World Wide Web Consortium (W3C). This reference includes accommodations for blindness and low vision, deafness and hearing loss, limited movement, speech disabilities, photosensitivity and more. For example, you should provide text alternatives for non-text content such as an image or a graph using the alt text HTML tag that accessibility software can use to describe what the image or the graph is. This is as simple as <img src=”smiley.jpg” alt=”Smiley face“>.

    Accessibility is too often forgotten or left to the later stages of app design. However, it is much more difficult to implement accessibility functions later on than if you plan for it upfront.

    Speed and Responsiveness

    User patience is shrinking and first impressions matter, so your app needs to start as quickly as possible. But it’s often easier said than done to get everything ready for user interaction within 1 second flat as certain operations, such as sending data to a server over a slow mobile network, can take a long time.

    So, given the challenges, how can you overcome them to provide a fast experience in your app?

    Start with performance-oriented design in mind, building the app logic in a way your users will perceive it as being fast at all times. You can, for example, implement caching and store the information presented to the user in the local cache. You can then use the cache to restore the last status almost instantaneously during startup while the app opens the network connection to the server and requests the data. Another characteristic of performance-oriented design is performance budget and code optimization. Performance budget means you set a performance baseline for a specific piece of code or functionality and put tools in place to ensure that baseline is not exceeded when releasing new code. Code optimization means trying new approaches to make the code run faster.

    Do this in the following cycle: optimize -> deploy -> measure.

    Repeat this cycle several times until your performance gains start to flatline. After this point, you can apply two concepts from the psychology world to make your app “feel faster” (aka “perceived performance” and “active waiting”).

    Perceived performance refers to how users perceive whether something is slow or fast, while active waiting refers to the fact that users perceive time as passing more quickly when they are engaged while they wait. So, when there is an operation where the user has to wait, you can incorporate some movement on the screen to draw the user’s attention—or, better yet, get them to interact with the app by providing a suggestion for optimizing their usage of the app or a curated quote. The chat app Slack does this pretty well.

    Network Awareness 

    Your app should keep track of network status, monitoring the available bandwidth and identifying when the network is not available at all. With this information, the app should adapt its behavior to improve the overall user experience. For example, let’s say the user is trying to send some data to the server while the network is not available. One solution is to switch the user to an offline mode, and let the user know they are offline and that the operation they are trying to do will be processed as soon as they are back online. At the same time, you could offer a cached version of the information, so the user can partially interact with the app.

    Network monitoring in your app should be planned carefully to avoid consuming too much power, which may impact the device’s battery life. For example, when the network is already active, you could send a few bytes to measure the latency to the server. You should avoid a constant network keep-alive, as actively maintaining the network even when there is no data to send or receive may impact the device’s energy resources.

    There are also intelligent edge solutions you can apply to your app that automatically adapt the compression of images depending on the network conditions. This means that the edge server can deliver a smaller version of the image for devices that have a slow network connection, without having to implement any logic on the app.

    Security

    Security is not an option, but a requirement that you should keep top of mind while building your application. The last thing you want is a security breach that compromises your users’ data or the integrity of your servers.

    For starters, ensure all your network connections are encrypted end to end and use secure protocols such as TLS v1.2 at the minimum or v1.3, which offer better security and a faster connection establishment. Ensure that your certificate offers strong ciphers that implement “perfect forward secrecy” (which makes it more difficult to be caught by man-in-the-middle attacks) and implement login techniques within the app that verify the user through secure techniques such as two-factor-authentication.

    You can also enhance your application security by implementing security measures at the edge such as automated bot protection. In this instance, machine learning technology in your edge servers can use device sensors such as the accelerometer to differentiate a real user from a bot that has stolen credentials and is trying to perform a malicious action.

    Coming up next in this three-part series: Everything you need to know about optimizing the back end.

    — Javier Garza

  • 9 Pillars of Continuous Security Best Practices

    9 Pillars of Continuous Security Best Practices

    Without proper consideration given to security best practices, the continuous delivery of software changes facilitated by DevOps is risky. On the other hand, DevOps provides an opportunity to reduce security risks if security is integrated into the continuous delivery pipeline according to best practices.

    This blog enumerates best practices for security across nine pillars of DevOps: Leadership, Collaborative Culture, Design for DevOps, Continuous Integration, Continuous Testing, Continuous Monitoring, Elastic Infrastructure, Continuous Delivery/Deployment and Continuous Security. Examples of best practices for each pillar are listed. These practices can be used to assess an organization’s maturity within the journey to Continuous Security, often referred to as DevSecOps.

    Leadership

    Leaders need to understand and sponsor a clear vision for security.

    • Leadership demonstrates a vision for organizational direction, team direction and three-year horizon including security practices.
    • Leaders intellectually stimulate the team status quo by encouraging asking new questions and question the basic assumptions about the work including security practices.
    • Leaders promote personal recognition by commending teams for better-than-average work, acknowledging improvements in the quality of work and personally compliment individuals’ outstanding work including security practices.

    Collaborative Culture

    Culture in organizations that work well with DevOps have a collaborative continuous security mindset.

    • The culture encourages cross-functional collaboration, shared responsibilities and avoids silos between developers, operations, project management, quality assurance and security.
    • The DevOps system (toolchain) is created by an expert team and reviewed by a coalition of stakeholders including security.
    • Changes to end-to-end DevOps workflows are led by an expert team and reviewed by a coalition of stakeholders including security.
    • DevOps culture empowers and trains team members to take personal responsibility for security, compliance and privacy obligations.
    • Security engineers/architects are involved in the design for modular components, and also consulted when security patterns change within modules.

    Design for DevOps

    Designing software for DevOps at speed requires application designers to master the best practices for continuous security.

    • Software source code changes are pre-checked with static analysis tools, prior to commit to the integration branch. This assures that the modified source code does not introduce critical software faults and security vulnerabilities such as memory leaks, uninitialized variables, array-boundary problems and SQL injection.
    • Software component analysis scans third-party components for known security vulnerabilities and identifies risk during the build process.
    • Security frameworks for technology stacks that are used (such as Apache Shiro or Spring Security) are documented and shared with developers for their respective technology stacks.
    • Software code changes peer code reviews include checks for defensive coding and security vulnerabilities prior to committing code to the integration/trunk branch.
    • Common security components such as identity, authorization, key management, audit/log, cryptography, protocols, etc. are maintained, published, readily available and used within module development.

    Continuous Integration

    Continuous integration (CI) within organizations that have multiple teams working concurrently on a project and different code bases is challenging. During the integration stage it is critical to assess the application and understand the impact of code changes from a security point of view.

    • A software version management system is used to manage versions of all changes to source code, executable images and tools used to create and test the software.
    • Incremental static analysis pre-commit and commit checks are wired into CI to catch common mistakes and anti-patterns quickly by only scanning the code that was changed. These checks identify security vulnerabilities through control flow and data flow analysis, pattern analysis and other techniques. These techniques find security-related issues such as mistakes in using crypto functions, configuration errors and potential injection vulnerabilities.
    • Binary artifacts are digitally signed and stored in secure repositories.
    • Changes to security patterns used within software source such as session management, authentication, authorization and encryption code trigger a notification or pull request to security engineers.

    Continuous Testing

    Continuous testing (CT) with DevOps has significant advantages for continuous security when best practices are followed.

    • New security tests that are necessary to test a software change are created together with the code and integrated into the trunk branch at the same time the code is. The new tests are then used to test the code after integration.
    • Security tests for each DevOps pipeline stage are automated and may be selected automatically according predefined criteria.
    • Release regression tests include security tests. At least 85 percent of the security regression tests are fully automated and the remaining are auto-assisted if portions must be performed manually.
    • Test results that indicate possible security concerns are tagged for security analysis.
    • Dynamic or interactive application security tests exercise the application for security vulnerabilities. Results of these tests are delivered to developers through tools and feedback loops native to their organization.
    • If containers are used, image repositories are scanned for images with known vulnerabilities, hash checks for image drifts and run-time checks for vulnerabilities during image deploys.
    • Attack patterns, abuse cases and tests are built for application module profiles.
    • Unit, functional and integration tests around—and especially outside—boundary conditions are run during CT. Tests include error handling, exception handling logic and negative tests.
    • Automated security attack testing to include the OWASP Top 10 in integrated into automated testing.

    Continuous Monitoring

    Continuous monitoring (CM) of security considers the dynamic nature of artifacts and infrastructure and a proliferation of objects and services to secure.

    • Metrics and thresholds are automatically gathered, calculated and made visible to anyone on the team that subscribes to them. Example security metrics include:
      • Number of security defects identified pre-production
      • Percent of code coverage from security testing
      • Number of failed builds due to security checks
      • Mean time to detection
      • Mean time to resolution
    • Vulnerability information in consolidated to provide a comprehensive view into vulnerability risks and remediation across tools, pipelines and apps—and over time.
    • Metrics and events from production security controls such as WAF, RASP, etc., are used to improve security testing.
    • Insight into security threats and events are shared and visible across DevOps teams to enable “attack-driven defense” methodologies.

    Continuous Security

    Continuous security (CS) is itself a distinct pillar with standalone best practices that cross all of the other pillars.

    • All information security platforms that are in use expose full functionality via APIs.
    • Immutable infrastructure mindsets are adopted to ensure production systems are locked down.
    • Security controls are automated so as not to impede DevOps agility.
    • Security tools are integrated into the CI/CD pipeline.
    • Source code for key intellectual property on build or test machines are only accessible by trusted users with credentials. Build and test scripts do not contain credentials to any system that has intellectual property.
    • External penetration tests (done out of band) are scheduled either periodically or on a regular cadence are used to perform deep-dive analysis.
    • Telemetry from production security controls such as WAF and RASP are delivered back to development teams to inform application updates.
    • Accurate inventory of all software packages and version information is documented via infrastructure as code. Automated detection is used to identify whether any of the packages have known CVEs associated and define specific remediation actions.

    Elastic Infrastructure

    Elastic infrastructure environments offer advantages compared to legacy or traditional static infrastructure. However, elastic infrastructures need to follow best practices for continuous security because flexible infrastructures offer a broader range of attack surfaces.

    • Configuration code includes automated checks including:
      • Ensuring unnecessary services are disabled and only ports that need to be open are.
      • Permissions on files, audit and logging policies are enforced.
      • Development tools are not installed on production.
    • Security-approved OS, software versions and frameworks are used to compose required infrastructure. Security-related controls such as ACLs and FIM are defined as a part of infrastructure where applicable.
    • A least-privilege model is enforced for processes running on shared infrastructure.
    • Smaller clusters are used to reduce complexity between teams.
    • Service provider partners security controls are validated to ensure they meet business requirements in their domains of the shared security model.
    • IaaS or PaaS service provider security controls are validated to ensure that they meet business requirements in their domains of the shared security model.

    Continuous Delivery/Deployment

    While DevOps enables new feature deliveries to users quickly, to minimize risk during deployment the following best practices are important:

    • Release-to-production decisions are determined according to predetermined metrics, which include security metrics.
    • A whitelist policy for application segmentation is enforced during deployment for each environment, especially production.
    • Continuous deployment processes trigger run-time security and compliance checks including:
      • Ensuring unnecessary services are disabled and only ports that need to be open are.
      • Permissions on files, audit and logging policies are enforced.
      • Verify development tools are not installed on production.
    • All secrets used for deployment are vaulted and retrieved programmatically during run-time or initialization of the continuous delivery process.

    In this article we detailed best practices for nine pillars of continuous security, otherwise known as DevSecOps. While is it clear that DevOps offers immense value for software deployment, the adherence to best practices is essential to reduce risk and assure security. Each organization is different and has different security postures. The specific practices, security tools and metrics that are appropriate may vary according to a risk assessment for each organization.

    Aggregation of end-to-end security metrics, from planning through to operations, is important but beyond the scope of this blog. End-to-end security monitoring tools, such as value stream management applied to DevSecOps and enterprise security dashboards, is a topic that we intend to cover in a subsequent blog.

    This article was co-authored by Imran Chaudhari. Imran is a principal security consultant at Trace3, where he assists clients in assessing and designing cybersecurity initiatives from a strategic, organizational, and technical perspective. His experience covers expertise in secure software development, application and cloud security, as well as identity and access management and DevSecOps assessments.

    — Marc Hornbeek

  • DevOps and Retail: Transforming Brick-and-Mortar to Brick-and-Click

    DevOps and Retail: Transforming Brick-and-Mortar to Brick-and-Click

    Brick-and mortar-retail is rapidly transforming with the digital age. As physical storefronts turn digital, it’s safe to say that traditional retail is quickly becoming a mesh of “brick-and-click.”

    So, how are retail giants surviving in this new landscape? Interestingly enough, the remaining brick-and-mortar retail are reinventing themselves by applying helpful DevOps principles.

    In this post, we’ll peek into cases of innovation and horror stories from historically brick-and-mortar retail chains and brands. From Target, to Balian Group, Sears and other companies, we’ll discover the importance of DevOps in this new brick-and-click multi-channel retail environment.

    Target

    In an effort to increase agility, Target engineering teams embrace something they call “the Dojo”—immersive, six-week training sessions with hands-on DevOps and Agile coaches. As Target CIO Mike McNamara recently told the Enterpriser’s project: “The Dojo has been fantastic in getting teams engaged with agile and DevOps, removing the natural resistance and fear of change, and then supporting the team through the changes while maintaining productivity. It’s been a huge success for Target.”

    The result of these sessions is increased comfort with methods including containerization and tools that enable continuous integration and continuous deployment. McNamara also noted their grassroots approach; they encourage open source activity and listen to their engineers when they petition the use of new tech.

    “Our engineers have fully embraced DevOps,” he said.

    Bailian Group

    For another case study, take Bailian Group, a large Shanghai retailer that operates 6,000 grocery and department stores. By the time Bailian entered the online marketplace, it suffered from a severe lack of agility, non-native web apps and underutilized server assets.

    “Our transition from traditional brick and mortar to omnichannel business presented a great opportunity but an equally large challenge,” noted Lu Qichuan, director of IaaS and Cloud Integration Architecture at the Bailian Group.

    Qichuan and Bailian realized that to stay relevant, they had to cut long development cycles and embrace “new cloud application development tools and processes that foster a CI/CD and DevOps culture and increase innovation and time-to-market,” he said.

    They ended up implementing a private cloud using OpenStack. Now, midway through their cloud transition, they estimate to have 10 million virtual machines by the end of 2020.

    Sears

    While the previous two examples had positive outcomes, digital transformation has not gone over well for other retailers. Sears declared bankruptcy in October 2018.

    In its final years, Sears was in a sticky situation. To the chagrin of former CEO Eddie Lambert, surveys found their customers preferred to shop in stores as opposed to online. Disregarding customer desires, however, Sears attempted a big data play with its “Shop Your Way” program, under which Sears gathered user data to then sell. The program floundered, resulting in consumer irritation and loss of sales as reported by Business Insider.

    Writing for InformationWeek, Emily Johnson reminded us that evaluating DevOps using the wrong metrics will ultimately lead to failure, citing customer satisfaction as the No. 1 goal.

    In its final years, an abrasive Sears leadership halted any sense of DevOps to flourish. A disengaged Sears CEO Lambert created “a climate of fear,” according to Busines Insider reports. It appears the retailers that stay afloat encourage agility and intrapreneurship—this means encouraging innovation, not fear.

    DevOps Aids the New Omnichannel Retail Benchmark

    Brick-and-mortar are evolving into omnichannel retailers that bridge physical and virtual spaces. Take IKEA’s augmented reality app, which visualizes items in a house. From Disney, to Startbucks, Nordstroms and elsewhere, physical storefronts embrace digital offshoots of their core model to augment the traditional retail experience.

    Surprisingly, physical storefronts aren’t completely dead. They still offer conveniences for urban environments with high walking scores. See the emergence of Amazon physical locations for ironic evidence of their benefit. Other storefronts and pop-up shops have taken on a museum-like quality. The flagship Funko store, for example, creates impressive displays and interactive exhibits, pulling in flocks of weekend shoppers that want more than a dull e-commerce shopping cart.

    DevOpsGroup similarly describes a “reverse showrooming” movement; consumers research products online to then purchase in person. This enables brands such as ASOS, which is emphasizing social media and free worldwide deliveries, to stay competitive.

    “Retailers have been forced to re-evaluate their business strategies and understand how new technologies will affect their offering,” according to the DevOpsGroup website.

    DevOps Turns Bricks to Clicks

    Online shopping has sufficiently disrupted retail, and brick-and-mortar must reinvent themselves to stay relevant. An open-minded leadership and a commitment to fast development, dynamic scaling, uncompromised availability and open source technology underpin a successful evolution.

    Of course, this increased reliance on technology necessitates a hardened look at how development and operations communicate, and brick-and-mortar retailers must adopt the behaviors of tech companies to retain agility.

    This may come in many forms: new user-facing digital experiences, microservices for composability in niche omnichannel environments, containerization to package code that scales well, distributed data stores, heightened user data security or smart incident management techniques, to name a few.

    Traditional retailers, then, should dissuade their doubts against agile. DevOps can aid retail by reducing redundancy, cutting costs and streamlining production and distribution.

    — Bill Doerrfeld

  • Feature Flagging Poised for Wider Adoption

    Feature Flagging Poised for Wider Adoption

    Feature flags, also known as feature toggles, provide a means for DevOps teams to test and add new capabilities to their applications without having to take the entire application offline. The downside is they generally result in more branches of applications that need to be carefully managed within the context of a DevOps process.

    A recent survey of 550 software developers and decision-makers conducted by the market research firm Vanson Bourne on behalf of Atlassian and Rollout.io, a provider of a platform for managing feature flags, suggests that IT organizations are getting more comfortable with managing feature flags.

    The survey finds 95 percent of survey respondents said their organizations have implemented, have begun implementing or plan to implement features flags. Those that have implemented feature flags said they add 30 new features on average to each application per year, compared to those that have only begun implementing (21) or plan to implement (18) them. A full 81 percent said use of feature flags will increase over the next 12 months, and 88 percent said modern software development should assume to include feature flagging.

    The primary driver for implementing feature flags are a need to reduce risk (46 percent), increase speed of development (46 percent) and increase speed of deployment (45 percent). Eighty-seven percent of respondents said enabling an on/off or “kill” switch for features also reduces the risk of application downtime for customers.

    A total of 97 percent of respondents said they are under pressure implement new application features faster, and yet 65 percent said it is difficult to accomplish that goal safely. More than 61 percent of respondents said their organization releases new versions or updates for applications once a week or more. However, 72 percent admitted they have lost customers or users due to application development errors.

    Rollout COO Ronit Belson said building out the functions required to manage feature flags doesn’t make much sense when platforms such as Rollout.io are now emerging. The survey finds nearly 90 percent of respondents who have implemented feature flags in-house would consider moving to a third-party supplier for feature flagging management software. A total of 37 percent of respondents said the cost of in-house development is higher and 32 percent said they encountered more complexity than anticipated.

    Belson added most organizations not only fail to appreciate the cost of implementing feature flagging on their own, but also the impact feature flagging has on the culture of the IT department.

    Thanks to the rise of microservices, feature flagging should become more prevalent as monolithic applications give way to a more granular approach to application development that makes it easier to isolate functionality. In fact, the ability to apply feature flagging might be considered one of the primary benefits of the agility inherent to any microservices architecture, especially it if relies on containers that can be easily ripped and replaced. The challenge organizations will face is implementing the DevOps processes required to embrace feature flagging at scale.

    — Mike Vizard

  • 7 DevOps Lessons in 2018: The Path to DevOps Success in 2019

    7 DevOps Lessons in 2018: The Path to DevOps Success in 2019

    We all learn from mistakes, right? But it would be better if we learned faster and didn’t repeat them in our future exercises. And this is exactly what we will discuss here in this blog.

    For a while now, we’ve been overwhelmed by the idea of the DevOps principle. We love how the collaboration between development and operations provides room for automation, continuous integration/delivery and enhanced time-to-market.

    But what about the tiny shortcomings we overlook in the process of continuous delivery?

    Listed below are some of the don’ts—or, rather, lessons learned from our DevOps implementation in 2018:

    Gauging Employee Capacity Over DevOps Delivery

    When Carmen DeArdo, Tasktop’s senior value stream management strategist, posed two questions to a crowd of 200 people, they had no answer to give. What were the questions, you might ask?

    • How many treat their delivery pipeline tooling as an integrated product with a product owner and an architect?
    • How many have any measure of how long it takes for them to deliver a feature or defect?

    Companies treat their delivery pipeline tooling as different components along the delivery chain. And, when it comes to measuring time taken, all that matters is getting the product to the finish line.

    These components are important if companies need to avoid obvious mistakes on the path to success. Consider the above questions the next time you set out on your DevOps mission. Within this aspect, measuring team happiness is as important as an integrated delivery pipeline tooling, and time is taken to introduce a feature.

    Companies need to strike a balance between managing work and achieving team happiness. This is important if the company has a long-term vision. Unhappy employees burdened with work don’t deliver the expected results. A sustainable pace helps companies ensure that employees don’t succumb to pressure.

    Revise the Management Strategy

    Organizations need to encourage their managers in a way that they are not put off by the DevOps process but rather motivated to build and maintain their team.

    Most organizations emphasize giving managers incentives to deliver expected results, maintain quality, expand team size, set immediate goals and rake larger profits. However, this strategy could backfire when applied to a DevOps implementation.

    Companies instead should encourage their managers to create an environment where the teams grow and become flexible, not only contributing to that process but also adding value to other processes, hence, the organization’s overall success. This thought process will lead to a chain of positive outcomes.

    Upskilled and Cross-Skilled

    Gone are the days when specializing in a particular skill was rewarding! The competitive market is looking for a workforce that is upskilled and cross-skilled. In short, employees need to be a package of multiple skills, with an emphasis on soft skills.

    Being multi-skilled not only supports transformational goals but also supports an organization’s goals. When the lack of new skills becomes a constraint, companies must invest in hiring individuals to propel transformation, which is equivalent to investing in automation.

    Automation ≠ DevOps Success

    Somewhere between adopting the DevOps culture and being DevOps-equipped, professionals have shifted from the purpose of DevOps to automation.

    In the process, people have lost control over the overall management of DevOps. Either professionals are in a situation in which the code is not built in the intended way or that the automated part is managed but the steps required for automation are not.

    Organizations instead should refocus their attention on the scalable nature of DevOps, building a new, fully automated process rather than automating an end-to-end process over time, as it is difficult and also time-consuming. Hence, automation does not equal the DevOps mission accomplished!

    From Idea to Blackboard

    DevOps once was more an idea of a team discussion rather than full-fledged process. But we saw 2018 transform DevOps from a mere idea to a part and parcel of everyday business—so much that it defines the way businesses plan their finances, regulations and organizational strategy as a whole.

    Additionally, DevOps experts in 2018 emphasized the need for value delivery than just focusing on details of technical practices. This can be achieved by constructing a managerial framework that bridges the gaps between business and technology.

    Relieve Your DevOps of Old Tech

    Last year also witnessed DevOps professionals moving toward new technology such as containers, Kubernetes and serverless. Why? It’s obviousthese technologies enable DevOps to deliver its promises. Trying to innovate the DevOps process or even innovate its end product with old technology will only take you backwards in the DevOps process.

    In 2019, we should realize that holding on to old technology will mean limiting your organization’s capabilities and impact.

    Identifying the Right DevOps Adoption Patterns

    While there are several DevOps adoption patterns out there, some organizations choose a central DevOps team enabling standard CI/CD tooling. The approach is in sync with DevOps thought leaders’ approach of reducing global complexity.

    However, this approach fails at catering to the needs of different teams. With the focus only on addressing CI/CD tooling, many centralized teams struggle with adoption.

    In another approach, companies seek to engage ambitious and autonomous tools to use DevOps tools and practices.

    This approach tends to match the common DevOps belief, ‘First prove that new work methods fit the enterprise, then spread.’ However, these teams are only successful in delivering projects with high levels of automation involved but have quickly failed to convert team-level experience to company-level.

    A 2019 DevOps adoption approach should focus on having high levels of team autonomy and reducing global complexity.

    Here are some tips to help you achieve this:

    • The central architecture team collect and share recommendations about languages, libraries and tools.
    • Teams consider these recommendations and experiment to see if there’s an opportunity for greater gain.
    • If things aren’t working, teams can change change and undo dead-end technology decisions/ideas.

    Now that we are ready with our lessons, it’s time to go live! Are you ready for your DevOps 2019 showdown?

    — Veritis

  • What To Do When Your DevOps Initiative is Failing

    What To Do When Your DevOps Initiative is Failing

    These days, it is difficult to find someone who hasn’t heard of DevOps. Statistics show that in 2017, just 6 percent of developers worldwide had never heard of it, and in 2018 this number decreased to 3 percent. You have to wonder who these 3 percent of developers are!

    Companies have been embracing DevOps initiatives with two core objectives: to reduce their time to market by delivering and deploying software faster, and to receive quicker feedback from customers. Many of these implementations have been successful. However, undertaking DevOps requires a major shift in terms of an organization’s culture and mindset, and companies often face difficulties.

    I want to examine some of the common challenges we see organizations facing and provide some best practices for overcoming them.

    Why do DevOps Initiatives Fail?

    Some of the core reasons DevOps initiatives fail include:

    • Not spreading a DevOps culture across the entire organization.
    • Choosing the tools without conducting research about what they do and evaluating whether they are a fit in your organization.
    • Setting unrealistic goals.
    • Trying to apply the same recipe that other companies have.
    • Not training your people.
    • Implementing a hybrid approach to DevOps where you attempt to keep your old culture.

    DevOps Initiatives Require Time and Patience

    Measuring your goals and monitoring your progress are the only ways to detect early warning signs that your DevOps initiative is not living up to expectations. But it’s important to note that patience is also required, as in most cases you will not achieve your objectives straight away.

    Getting to a full DevOps environment is not easy, particularly in large organizations, which are used to having siloed structures in their development process. So, start from the bottom up. Establish small goals that should be achievable, such as increasing the unit test coverage, improving the automation suit, reducing the time from code-commit to testing-ready. Measure these and use the results as possible warning signs or alert signals.

    There are also a series of steps you can take to put an initiative back on course. First, re-evaluate the process or processes you are having difficulties with and evaluate if:

    • The right metrics have been set and you are monitoring them.
    • The people applying the initiative are engaged with the DevOps culture, particularly if they are in different areas.
    • You have chosen the right tools.

    The Entire Organization is Responsible for Achieving DevOps Success

    In DevOps, the whole organization should be responsible if the DevOps initiative fails. There shouldn’t be one DevOps department or one person in charge of it; DevOps should be adopted by everyone, following the same path as Agile development. After all, they complement each other.

    Those companies that have successfully implemented DevOps have developed a strategy that fits the specific needs and demands of their organization. Although I’m currently mentioning some strategies that help companies achieve success with their implementation, there is no “magic” DevOps formula. A common mistake companies make when trying to fix a sub-par DevOps initiative is to simply copy what other companies do. Most of these companies end up abandoning the initiative because the outcome is not what they expected.

    Finally, if you’re planning to start implementing DevOps, keep in mind that it’s a process in which technical tools are as important as spreading a new culture based on collaboration, multidisciplinary, autonomy and open-mindedness. As this article points out, in many cases, the blockers to achieving success with DevOps are human, not technical.

    — Gabriel Vasquez