devopsy.kinsta.cloud

Tag: devops

  • How DevOps-Savvy Are You? (Quiz)

    How DevOps-Savvy Are You? (Quiz)

    As DevOps tools become more and more prominent in the IT landscape, it wouldn’t hurt IT professionals to brush up on their knowledge. DevOps has helped IT departments that are grappling with mobility, cloud and other methods which are revolutionizing how companies create and deploy applications. Traditional silos are being demolished and, for many, DevOps holds the key to solving the challenges modern IT departments are facing. Through configuration management and automated testing, DevOps tools provide a consistent and repeatable outcome.

    Regardless of whether it is part of your everyday job or whether you simply want to master the rudiments, as an IT professional you need at least some DevOps knowledge. Luckily, the folks at Squadex have created a quiz to help you see how much you already know and how much you still need to learn.

    Up for the challenge? Then let’s go! Click on the image below to get started:

    — Stas Ivaschenko

  • CI/CD and its Effects on Release Managers

    CI/CD and its Effects on Release Managers

    The role of release management in the development of any software package has drastically changed with the introduction of continuous integration and continuous delivery (CI/CD).

    CI/CD has made the development process more agile, and it has made the role of release management significantly more challenging. To understand and grasp the changes brought into the role of release management, it is imperative to understand release cycles before and after the incorporation of CI/CD.

    Release Cycles before CI/CD

    In the past, most of the software houses had unidirectional release cycle that comprised of five components:

    1. Research
    2. Plan
    3. Development
    4. Test
    5. Release

    These are the usual steps of any release cycle. In general the development and testing phases of the cycle are lengthy as compared to the other phases. However, there is no proper feedback mechanism in the old release cycles.

    Then Comes CI/CD

    The overall framework of release cycle has changed with the introduction of CI/CD practices. Both of these protocols are related to the development phase of the cycle and are practiced to make the process more rapid, responsive and adaptive.

    Continuous Integration

    Continuous integration is the practice by which developers are required to integrate the developed codes into a common software repository. That repository receives multiple entries every day, each of which is verified and checked through an automated build. This routine helps teams with quick and early detection and location of any issue with the coding.

    Several benefits of continuous integration are:

    • Teams spend less time in debugging the coding problems.
    • System integration becomes convenient.
    • Developers don’t have to wait to check the viability of their coding.

    Continuous Delivery

    The practices of continuous integration are extended to continuous delivery, the process through which release managers ensure that every bit of alteration in the system or package are releasable at any point in the cycle. Continuous delivery helps large software organizations streamline their releases with more adaptability per feedback, changed strategy and market trends. In making release cycles more agile and smooth, modern release management plays a decisive role.

    Continuous Deployment

    Continuous deployment follows the continuous delivery methodology, in that every change and patch that goes through agile testing automatically gets deployed to the production. Continuous deployment reduces the lead time which results in quicker ROIs and feedbacks. Organizations not burdened by unnecessary regulations can make the most of continuous deployment.

    Release Managers’ Role in the Era of CI/CD

    As with the incorporation of CI/CD in the development and release of any software package, release cycles have become continual. This has brought about a significant shift in release managers’ responsibilities, including those discussed here.

    Shift from Linear Phase to Operations

    In the past, release managers usually would supervise the linear phases (planning, development and testing) that culminate into a final release. Now, with the advent of CI/CD, release managers are responsible for taking care of the operational side of things. For instance, a modern release manager has to ensure a smooth flow of continuous integration of codes to the production team.

    More Fronts to Deal With

    Modern release managers are no longer limited to development and quality assurance. They have to deal on several fronts. Because of continuous delivery, speed is now associated with releases. Hence, release managers are required to deal with sales and support, management/marketing, and customer feedback to ensure the required changes in the next release.

    Modern Release Manager as a QA Manager

    Before the new paradigm of CI/CD, release managers solely relied upon the reports from the quality assurance (QA) manager to determine and access the release quality. With more automation involved in software development, the tasks of QA managers have shifted to release managers. With the help of layered test automation suites, a release manager now has to assure the quality of release from development to production.

    Release Management Ensures Swift Decision-Making

    In the past, a whole board of decision makers would decide whether to release the software product, or not. But with fast and never-ending cycle of releases, this collective decision-making was lagging in the process of a release. Therefore, release managers are now required to come up with decisive final report, which enables even a single stakeholder to call the shots.

    Complete Understanding of CI/CD Pipelines and Other Related Technical Aspects

    Release managers today must have comprehensive knowledge of CI/CD protocols and DevOps auto deployment tools. They must understand how the CI/CD pipeline, which is central to the quick release cycle, works, and be able to identify defects early. In addition, release managers must understand:

    • Feature Toggles: A unique prevailing tool that enables developers to amend system behavior without altering the code, to help expedite the release cycle.
    • Branch Handling: Used for parallel development of different patches of software.

    CI/CD is still in its nascent phase and therefore faces the issues of lack of management and infrastructure. Due to these shortcomings, Some naysayers also question its viability. It becomes, then, a shared responsibility between all departments—including release management—to address the concerns and meet the challenges in a better way.

    In this backdrop, below are some important points integral to the release management role.

    • Quality of release must not suffer for the sake of agility.
    • An appropriate change notification system must be implemented so every stakeholder can know which patch is about to release and when.
    • With release becoming more of a continuous progress rather than an event, it is important for release management to make sure that the power of decision-making resides with small, independent release teams to have smooth deployment process.

    Apart from the explicit responsibilities of release management discussed above, they must have the requisite interpersonal skill set to implement and steer the changes in the work culture, as well as structure the hierarchy of the team. Furthermore, they should have a thorough grasp of the tools and processes that are necessary in the CI/CD integrated working environment.

    There is no doubt that the job of release manager has become more demanding with the introduction of CI/CD. But on the bright side, release management has become the linchpin of any software release that is developed in the environment of CI/CD.

    — Subramonian

  • What Can Conway’s Law Teach Us About DevOps?

    What Can Conway’s Law Teach Us About DevOps?

    I first heard about Conway’s Law from reading the “DevOps Handbook” (an excellent read, by the way, if you want to dive head-first into DevOps). I was intrigued by how this idea came from slightly left field, yet seemed to have big implications for businesses on their journey to increased efficiency.

    In this blog, I will share my understanding of what Conway’s Law is and how it is relevant for your business, whether you are in the middle of a DevOps transformation or just taking your first steps.

    What is Conway’s Law?

    In 1967, Dr Melvin Conway submitted a paper to Harvard Business Review. It stated the following observation: “Organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.”

    This statement was later dubbed “Conway’s Law“.

    What Conway’s Law Means for the DevOps Journey

    Conway’s Law explicitly mentions the system design and communication structure. However, this idea can also be extended to include team structure, which is usually aligned either to systems structure or communication channels.

    When it comes to delivering streamlined and efficient change, Conway’s Law suggests that we should align all these areas to the overall business model. This is a concept that also sits at the heart of DevOps, and is a cornerstone for improving efficiency and overcoming delivery bottlenecks.

    The Importance of Alignment

    Alignment between these four areas is critical for becoming truly agile and thriving in today’s online and digital world. Without it we will hampered by heavyweight handoffs, conflicting team goals, and resistance to change.

    The larger the organization and the more siloed the teams, the more pronounced the constraint described by Conway’s Law is. However, organizations with more nimble, collaborative teams are free to design their systems in the most efficient way, not restricted by inefficient wasteful processes.

    Dealing with Misaligned Team Structures

    In IT, with its constant flow of new projects and requirements, we are always improving our systems in response to changing strategies and directions from the business. So why shouldn’t we have the same mindset when thinking about our team structures?

    If our team structures aren’t evolving to meet the current needs, then we are inadvertently constraining ourselves to only deliver solutions that fit in with our existing team structures. This makes innovation difficult. Similarly, we need to mold our communication and collaboration structures into the right shape for our systems, based on business goals. This will, in turn, define how we organize our teams.

    With knowledge and understanding of Conway’s Law, we can actively design systems, team structures and communication channels to avoid the pitfalls of misalignment.

    Overcoming DevOps ROI Barriers

    DevOps is an incredibly powerful approach to IT. But for DevOps to provide value to your organization, you need to address team silos and collaboration gaps. If you cannot align collaboration channels with your business needs, then no amount of automation or DevOps change will help your business to achieve agility.

    For some businesses, team structures may need to change dramatically. For others, it may just be a case of increasing collaboration between specific teams, or creating ways to improve the efficiency of handoffs and reduce wastage in processes.

    Aligning Teams to Business Goals

    Overall business success isn’t siloed, and team/department success shouldn’t be either. Sharing KPIs and dashboards is one important way of ensuring that teams stay aligned to business goals by improving staff mindset and reducing distraction.

    So what do fully aligned teams look like? In businesses delivering IT change, teams will be aligned to products or market sectors. This means each team will be as autonomous as possible, without cumbersome handoffs.

    Often aligned teams will incorporate all speciality skills (such as information security, infrastructure and DBA) within their own team. However, it is becoming more common to solve the alignment problem by improving the efficiency of interactions between teams through self-service. For example, self-service environment provisioning enables delivery teams to function independently throughout the delivery life cycle without any environment requests or delays.

    The Art of Collaboration

    We are currently seeing a big shift in culture across many organizations, powered by the fast uptake of new collaboration systems. Tools such as MS Teams, Slack and HipChat remove barriers between teams and improve communication, making it easier to align collaboration channels with your business goals.

    However, just using a shared collaboration tool does not guarantee streamlined business delivery. While it may be quick and easy to create a new channel or chat group, creating a culture where collaboration evolves alongside business needs is much more difficult.

    The key to a collaborative culture is trust. Everyone needs to know that the entire team is working toward the same end goal, with shared responsibility for the results.

    Closing Thoughts

    When staff are in heavily siloed teams, they can be easily diverted away from the business goals. Staff might also resist change as they haven’t got the business view. But when teams, systems, and collaboration channels are fully aligned to the business goals, all employees will understand their impact on the business—and measure their success against the business success.

    I hope this insight into DevOps from the perspective of Conway’s Law was useful, and you have some ideas to foster greater collaboration and efficiency in your business.

    — Bronwyn Davies

  • DevOps in the Cloud: Security’s Groundhog Day

    DevOps in the Cloud: Security’s Groundhog Day

    Throughout the internet age, enterprise IT has given security a lower priority than qualities such as speed-to-deployment, scalability, availability and usability. We first saw this in the late 1990s and early 2000s, when IT teams rushed applications onto the web. Amid the glee surrounding the potential of fancy new internet architectures, few thought about the possibility that these applications could become portals into the enterprise for criminals. So, the credo among development organizations was “move fast, deploy fast and seize the future.” There was no concept of risk management, beyond considerations such as availability, scalability and usability. This laid fertile soil for what would become the breach epidemic.

    As we progressed through the years, breaches became so common and massive as a result of the “web evolution” and there became a dire need to manage information security risk. Thus, enterprise security was born. As it evolved, these departments worked closely with IT management, development, infrastructure and business teams to create frameworks that aligned business goals, risk, security and agility. Security and risk management became important parts of development processes and business operations.

    Finally, there seemed to be a path forward to a more secure future … until the future changed.

    Related Content:

    How Developers Can Take a More Proactive Approach to Security

    How Blockchain Tech Can Make DevOps Better

    The future became the cloud revolution, and it plunged us back into the same festering pool of security negligence that we saw two decades ago. Indeed, when it comes to deploying applications in the cloud, security professionals likely can relate to Bill Murray’s character in “Groundhog Day.” Only in the real-life case, they repeatedly relive the same scenario regardless of what they do.

    As DevOps Teams Gain Power, Things Become Less Secure

    Since the emergence of cloud computing, enterprises once again have rushed to take advantage of a new deployment paradigm, and they are prioritizing factors such as scalability, availability and cost-containment, leaving security as an afterthought. As DevOps teams lead today’s much-ballyhooed business transformation initiatives, they gain elevated status within companies.

    Perhaps the most critical development has been DevOps teams gaining control over infrastructure, not to mention development and even corporate purse strings. While these teams follow their own best practices, their processes and protocols often don’t align with their organization’s enterprise security model. Additionally, many cloud providers increasingly are working directly with DevOps personnel, circumventing IT, security and business teams. Not only has this eradicated the interdepartmental collaboration that emerged to manage risk following the first generation of internet applications, but traditional IT and IT security processes have been disintermediated.

    The net result is that, even if a company understands the importance of security, no one team or individual is directly responsible for it because those personnel have been disintermediated. This leaves a gaping hole in enterprise cloud strategies, which is due in large part to confusion related to the shared responsibility model in cloud computing. Many organizations incorrectly assume that cloud platform security equates to application security. But, just because a cloud provider is HIPAA-compliant, for example, doesn’t mean an application deployed within that environment is as well.

    We have critical business applications exposed to a brand-new environment—and security is nowhere in sight. Companies are moving forward with cloud migration without fully understanding what their requirements should be or for what the business, IT and security teams are responsible, paving the way for a second iteration of the breach epidemic. Welcome to “Security’s Groundhog Day.” 

    Securing Cloud Migration and DevOps Processes

    We don’t have to make the same mistakes with the cloud that companies made when they first deployed web-enabled applications in-house. We can break the repetitive cycle by making security and risk management a fundamental part of cloud migration and DevOps processes. Here are a few ways to accomplish this:

    • Know your data. Everyone within your organization has a responsibility to understand what types of data are moving to the cloud on a per app basis, as well as exactly what types of controls are required to mitigate enterprise risk associated with that data.
    • Use a matrix of reference architecture to design secure-by-default solutions to meet varying workload requirements. This will help DevOps teams know when to apply more arduous requirements and when lower risk data needs fewer controls.
    • Verify your plans regularly. Agility requires compromises, and the cloud moves quickly. Without continuous monitoring and rigorous testing, you can’t be sure that what you wanted to build actually made it into production.

    Ending ‘Groundhog Day’

    Many companies are forging ahead with DevOps in the cloud without giving security a second thought, and the resulting consequences are giving other organizations pause. In the movie “Groundhog Day,” Bill Murray’s character had to re-examine his life to break the endless time loop. DevOps would be well-served to do the same: to rethink security and make it a focal point in cloud migration and processes. This is how DevOps can avoid repeating the mistakes of the past. Most importantly, there needs to be a change in the DevOps mindset.

    Security should not be the reason organizations are saying “no” to cloud adoption. When engaged as part of the process, it actually becomes the key to unlock the cloud. Making security part of the process is how you avoid “Groundhog Day”!

    — John Turner

  • Dev vs. Ops Needs for Large-Scale Version Control Systems

    Dev vs. Ops Needs for Large-Scale Version Control Systems

    Distributed version control systems (DVCS) such as Git (introduced in 2005 by Linus Torvalds, the creator of Linux) rapidly gained worldwide acceptance by the global software development community. DVCS offer very fast, lightweight and local software change control capabilities that support many parallel code branches across large project code bases. These are compelling benefits for individual developers and development teams. At their heart, DVCS accomplish this by tracking software changes as a series of file system snapshots in local repositories instead of via management of individual file changes in a central database. “A Short History of Git” explains this in more detail.

    The DVCS approach is ideal for individuals and small agile teams because it puts control directly in their hands without the need to transact all file changes with burdensome systems that were designed using a central management paradigm.
    However, the distributed approach taken by DVCS has historically presented challenges for operations, especially when large-scale enterprise software systems consisting of components from many separate repositories need to be managed and controlled. Enterprises with many developers, large source or binary files (e.g. graphics, audio or video), many artifacts or many large containers need granular end-to-end version traceability. Enterprise-class support requirements exceed the original design intentions of DVCS.

    End-to-end software version management offerings that on one hand leverage efficiencies of distributed systems for developers yet still support scalable operations are required to address the needs of Dev and Ops communities in enterprises with large software version management needs. These complementary requirements have driven the evolution and best practices of large-scale hybrid version control systems:

    • Simplify builds and manage complex projects by organizing multiple repositories
    • Move code and build assets into the DevOps pipeline quickly
    • Improve performance for remote sites by using a central system as a proxy/cache
    • Speed up many activities at the system level, such as cloning and copying code
    • Implement a seamless workflow that incorporates assets such as large graphics and binaries, in addition to source code

    Related Content:

    35+ Tools Every DevOps Expert Must Know

    Automation: Achieving Faster Rollouts with Better Accuracy

    As stated, historically, these were problems that could only be addressed by a centralized version control offering. DVCS alone simply couldn’t handle the large-scale continuous integration (CI) and operations requirements of large-scale software development communities. While there are still inherent issues in the way DVCS manages large binary assets, select vendors have begun to tackle the problem by mirroring DVCS repos in real time, which marries the developers’ need for easy branching and local control with the operations team’s needs for faster and more efficient builds.

    For enterprises developing complex software incorporating both binary and text-based assets, large-scale enterprise hybrid version control systems with supporting both distributed and centralized structures offer a best practice solution. They provide capabilities for a global single source of truth, replication of all types of artifacts and manage versions of everything from planning to release. By resolving operational management problems resulting from sprawl of individual Git repositories, while at the same time preserving benefits of distributed systems, today’s enterprise-class centralized and/or hybrid version control systems can meet the needs of both Dev and Ops without sacrificing efficiency or operations control.

    Summary

    What do you think? Do you agree that the benefits of hybrid versions control systems listed above are important to achieving large-scale version control? Are there other solutions you recommend?

    — Marc Hornbeek

  • IBM Z: It’s Not the Dog. It’s the Trick

    IBM Z: It’s Not the Dog. It’s the Trick

    There’s a piece of conventional wisdom that runs rampant in the tech-o-sphere: You can’t teach an old dog new tricks. Supposedly, once people become enamored with a technology and use it for a long period, they are loathe to adopt new ones. We’ve all heard it, and some believe it. Me? I not buying it any more than I believe that you can’t teach a new dog old tricks. From where I stand, a good trick is a good trick, period!

    So let’s talk about a really good trick: mainframe computing. It’s technology that is used by many business sectors—airlines, insurance companies and banks. And, it’s been designed from inception to support interaction from hundreds—if not thousands—of users. Yet, many perceive the trick to be old dog, that’s it’s not applicable to modern computing.

    Actually, the opposite is true. It’s an important trick that should be used by any dog, new or old. It’s a question of adaptability: how to make the trick useful in any circumstance.

    Let’s put the trick-and-dog analogy aside and talk directly. Companies are sitting on a boatload of mainframe assets that can and should be leveraged for use in this world of mobile devices, APIs, microservices and speed-of-light DevOps deployment practices. The question is, how?

    To make mainframe technology viable in modern cloud-based paradigms, it must satisfy four conditions. The technology must:

    • Support information exchange using modern API standards;
    • Support coding in modern programming environments;
    • Support automated testing throughout the deployment pipeline; and
    • Be deployable according DevOps best practices.

    IBM Z, a mainframe-based technology, has done a great job of meeting these conditions. The various products and  toolsets that IBM provides for IBM Z technology make working with IBM Z in today’s cloud computing environment surprisingly easy. Let’s take a look at the details.

    Supporting REST APIs for Information Exchange

    REST is fasting becoming the standard by which information is exchanged between systems over the internet. As mobile devices and the internet of things grow as the means by which users interact with applications, the data these applications require is accessed in real time using REST. Today, REST is a first-class citizen in IBM Z technology. A key feature of IBM Z Application Discovery and Delivery Intelligence (ADDI) is the capability to discover  applications running on IBM Z hardware and identify them as potential  REST API candidates. Support for REST makes IBM Z applications consumable to a wide variety of computing devices. Also , supporting REST means that IBM Z applications integrate easily with standard DevOps testing and deployment practices.

    ADDI provides the support for REST that allows IBM Z to be an agnostic resource on the internet

    In the world of modern, cloud-based computing REST is the lingua franca of information exchange. Supporting REST makes IBM Z data and transactions available to the modern digital ecosystem.

    Support for COBOL and PL/1 Programming Using the Eclipse IDE

    The IBM Explorer for z/OS, which is part of the Application Delivery Foundation for z Systems (ADFz) tool suite, allows COBOL and PL/1 developers to code in the Eclipse Integrated Development Environment (IDE). Eclipse is well-known to a broad range of developers working in languages such as Java, PHP, Node and Python. Using Eclipse to do IBM Z programming under COBOL and PL/1 allows developers to have a shared programming experience and increase their productivity by an average of 15 percent.

    Although the actual lines of code the developer creates will be particular to the developer’s programming language of choice, the unit testing and debugging experience Eclipse provides is similar regardless of language. A developer uses Eclipse to unit test code as it’s being developed. If the test fails, the developer sets breakpoints and starts the debugging session to inspect the code at runtime. The way code-test-code-debug is conducted in Eclipse is consistent. Thus, the skills acquired using the Eclipse IDE are easily transferable between languages.

    Having all developers work in a common development environment creates a shared experience—an important step toward breaking down organizational silos. Reducing the silos that isolate knowledge workers from each other so they can collaborate better and faster across teams and geographies, combined with deploying code in an automated CI/CD pipeline, significantly speeds a company’s ability to get code to market while also making collaboration easier across teams and across geographies.

    Support for a Wide Range of Testing Techniques

    For a software development framework to be viable in a CI/CD infrastructure, it must support a wide variety of testing capabilities. In addition, testing needs to be verified via automation. As mentioned above, IBM Explorer for z/OS allows developers to create unit tests on COBOL and PL/1 code. Once unit tests are created, they can be automated for use throughout the development pipeline. Test reuse via automation speeds up the deployment process significantly.

    However, testing at the code level is not enough. As code moves through the modern deployment pipeline, it must be subjected to load and performance testing. Test engineers accustomed to using mainstream tools such as Apache JMeter or Rational Performance Tester will have little problem using IBM Z Workload Simulator for z/OS to do load and performance testing. The concepts behind load and performance testing are similar, regardless of the language and environment driving the development process. For example, Workload Simulator for z/OS allows test engineers to emulate hundreds, if not thousands, of users to exercise the software under test. Being able to create stress on a system in a controlled, reportable manner is critical for getting good performance testing metrics.

    Supporting the DevOps Deployment Practices

    Basic to DevOps best practices is the notion of releasing quality software quickly and incrementally. Instead of waiting months to do a release that has many features, the DevOps practice is to release one feature at a time, as quickly as possible. In the DevOps world, release cycles are no longer a matter of weeks and months, but rather days, if not hours. To achieve the fast release cycles emblematic of DevOps, management of the deployment pipeline must be automated.

    However, when it comes to mainframe assets there is a hitch in terms of deployment units. In the microcomputing software environment, deployment units typically take the form of an executable file, supporting dependency file or script file such as .exe, .jar, .js or .py. Also, given the rise of container technology, the deployment unit can be the container itself. In terms of IBM Z, the deployment units are the file and the job.

    Engineers at IBM Z have taken the clever approach to managing asset deployment. File and jobs have become abstracted deployment units accessible via the IBM Explorer for z/OS Atlas APIs. Thus, IBM Z components can be treated as any other artifact in the deployment pipeline. DevOps engineers use the APIs exposed by Atlas to cancel a job or delete an associated file. Standardizing direct access to the IBM Z deployment pipeline using REST APIs gives DevOps engineers the flexibility required to get working code released quickly.

    DevOps engineers not only can automate the pipeline, but should ad hoc intervention be required, they also can use the Atlas APIs to make the changes required at a moment’s notice. Combining the Atlas APIs with ADDI’s ability to collect, correlate, calculate and produce mission-critical application and testing health metrics, as well as trend analytics, makes IBM Z a first-order participant in the world of cognitive DevOps.

    Putting It All Together

    One of the great things that the internet has done is to create a standardized way by which any computing system can interact with another. As long the system supports REST, regardless of whether it’s a smartwatch, a cellphone or a large-scale computing environment such as IBM Z, it’s a leveragable asset on the internet. And, if the system meets the conditions that define DevOps best practices, it can be managed with the degree of control and predictability required to participate in the breakneck release cycles that are part of modern software development. It really doesn’t matter whether the system is new or old, as long as it can adapt to present demands. Adaptability is key to longevity, no matter the age of the dog or the trick.

    — Bob Reselman

  • How DevOps is Vital for SaaS Entrepreneurs

    How DevOps is Vital for SaaS Entrepreneurs

    Software as a service (Saas) is widely regarded as the most lucrative and compelling of the three cloud business and operation models. This is because it transfers the most technical support expenses and can be sold directly to the customer. However, despite the inherent value of the business model, many entrepreneurs will be hard-pressed to take full advantage of it without some additional technical and cultural assistance.

    Integrating DevOps into the SaaS Product

    Successful integration of SaaS applications involves immersion at the highest level—either that or the product has to be manufactured using one strategy from the very start. The construction and sustenance of SaaS applications therefore, needs to be done with DevOps as the operating system, per se.

    In a broader sense, for a SaaS entrepreneur, success means the following:

    • Ability to deliver code much more reliably, and quickly.
    • A marvelous experience for customers.
    • A resilient, scalable application environment.

    All of the above is achievable by integrating DevOps throughout the developmental process, without which the construction of SaaS applications could become an operational nightmare. This is true for both grassroots SaaS entrepreneurs and cloud providers.

    Advantages of DevOps Automation

    For the modern SaaS entrepreneur whose entire business and operational foundation is the cloud, following are some of the advantages held by DevOps from a technical standpoint.

    • DevOps automation has the capacity to make continuous and uninterrupted delivery a possibility.
    • Automation itself has benefits in terms of numbers and innovations. A good example of this would be the LaserJet firmware team at Hewlett Packard. Simply via automation, the team was able to free more time for innovation and the development of new features by a margin of 700 percent.
    • Scalability of the SaaS applications, as well as any major software, can be ramped up to unprecedented levels of expansion via DevOps automation and back-end development.
    • Resiliency, which has always been an issue with cloud-based applications, can be ingrained into the developmental process itself, thus producing a final product that is resilient and dependable for the customer.
    • When integrated with the functionality and practicality of class-leading cloud computing services such as Amazon Web Services (AWS), the aforementioned scalability, resilience and uninterrupted delivery can be achieved with considerably more ease.

    Rapid Delivery of New Code

    The first advantage of DevOps automation toward SaaS entrepreneurs can actually be proven in a practical sense. Since continuous delivery spells the difference between application success and failure, it pays dividends to be free of interruptions and bugs, which can take away from the end user experience. This also will help you get a leg up against both the startup and established, enterprise-stage SaaS operator.

    With the automation of each environment build, from the development stage and QA to production, DevOps allows you to release new code as often as need be rather than adhering to scheduled and timed releases of code. In turn, this allows you to make vital decisions and resolve issues in real time, negating the need for a repair meet.

    According to the “State of DevOps Report” for 2015 by Puppet Labs, companies which utilize DevOps possess the capacity to launch code up to 30 times as often, and have lead times that are 200 times shorter. Not just that, but they have a failure recovery rate that is 168 times that of the average company that has yet to implement DevOps automation.

    Using DevOps to Provide a Better SaaS Experience

    SaaS entrepreneurs should begin their DevOps strategy by setting DevOps configuration needs for the particular application as it is being constructed. This would usually contain the provisioning regulations, including database instances, network addressing and the arrangement of software instances.

    The specific capabilities of a number of DevOps tools can and do vary here, which is why it is necessary to review the needs of the application against the work plan and the features of the project. This is to ensure that all the plans are headed in the correct direction.

    As most applications that have been deployed into the cloud are highly unlikely to have a DevOps model-based design element, it can be to the advantages of the SaaS entrepreneur to verify whether any DevOps tools under evaluation offer the capability to design a template. This is to describe deployment independently of the development process, which can be aligned with legacy applications.

    Aside from the value of DevOps in the development of SaaS applications that run on the very infrastructure the cloud provider offers, DevOps also can be utilized to assist with the migration of applications to other cloud computing models such as platform as a service (PaaS) and infrastructure as a service (IaaS). It also be used for the integration of several providers across a single cloud federation.

    Since SaaS is currently being used by the majority of enterprises (67 percent, according to a UBM survey), it makes sense to focus on DevOps practices for organizational success.

    Since SaaS has the lowest tolerance and margin for error, especially in the uber-competitive landscape that the modern SaaS entrepreneur has to operate in, using DevOps can potentially provide a significant advantage in terms of the following:

    • Major increments of cloud profitability and customer satisfaction.
    • The ability to deliver updates and new products at a much more rapid pace.
    • Fewer interruptions across the delivery channels due to the improved developmental process.

    With the cloud market as competitive as it is, it is necessary to have the best development and operations approach. Also important is the culture in which the applications potentially will take shape and the values that will be integrated and ingrained within them.

    In Conclusion

    It is said within the cloud-based entrepreneur community that although the SaaS environment has improved significantly over the past few years, it has by no means edged out the DevOps approach. The future of both the cloud and DevOps is entwined, and entrepreneurs should accept the fact that a year or two down the line, they will be synonymous with each other.

    This makes is absolutely vital to get the correct approach early on, and already have an infrastructure based on DevOps, so that competition in the future can be facilitated and made considerably easier, and customer experience can be harnessed for enterprise success.

    — Subramonian

  • ‘Let the Developer Choose the Language’: Too Much of a Good Thing

    ‘Let the Developer Choose the Language’: Too Much of a Good Thing

    As more and more enterprises drive into the DevOps space, this is less of an issue, but you still hear stories that make one cringe. The idea of DevOps (and, by extension, agile) is to get products to market faster and spend less time managing/fixing. Some take the idea to be freedom to choose—and it is to some extent, as long as an organization remembers that it can be (and often is) an increasing management nightmare to pile on product after product. DevOps already demands a fair number of new products to manage, so standardizing those products is imperative to the long-term success of DevOps in the organization.

    Technically, each team could choose its own toolchain, programming languages and data stores in a vacuum, ignoring the rest of the organization. But that is a terrible direction to take in almost every scenario. Yes, we have a lot more choices for languages and environments, and most of DevOps is still in development stages, so there are a ton of products to choose from. But because you can have them all in production doesn’t mean you should. I still see some pundits saying, “Let the developer choose the language.” That’s fine, as long as part of “choose the language” is “with our current architecture as the default.” Five languages or three CI/CD tools or several ARA tools is overhead—overhead to maintain, to keep skills current in and to troubleshoot. And it is overhead that isn’t going away without a project to replace it.

    I’ve written about this before, and yeah, this is the agile/DevOps technical debt. It happens more than you’d think, and yes the product gets to market fast, but if the life expectancy of the product in question is more than a year, you’re going to be maintaining it quite a bit. People who point to microservices or serverless and say, “Each could be in a different language!” have never worked in a long-term maintenance setting, I would guess. It’s hard enough to eliminate redundancies that had to happen in the normal course of business/application growth; making it worse by creating redundancies based on developer whim is just a bad idea.

    That could be my experience talking. I’ve lived through the “No, we can’t do that because the backend is written in (insert obscure toolset), and it won’t integrate with (insert technology du jour)” conversations. Both as a developer and as a manager. It creates future problems that didn’t have to be.

    Dalibor Siroky hinted at this problem in point number three of his “Five Biggest Ways to Fail at DevOps” article, but I thought it needed a bit of an expansion. Again.

    Keep kicking it, bring in new tools that add value, but don’t just build redundant chains because Developer Don is most comfortable with the programming language emoji.

    — Don Macvittie

  • Predictions for DevOps Security in 2018

    Predictions for DevOps Security in 2018

    Automation continues to be a major driver of DevOps as a whole. In 2018, we’ll continue to see a shift in how and where automation is applied in the DevOps life cycle. More specifically, DevOps will move toward adoption of integrated automation and security orchestration solutions. The need to move away from a reactive DevOps security model will see more teams integrating new solutions that leverage machine learning, analytics and orchestration that can provide incident management insights in real time. Based on that approach, here are three security predictions for DevOps in 2018.

    Continuous Response Will Become a Fundamental Part of the CI/CD Process in 2018

    DevSecOps will increasingly integrate security into the continuous integration/continuous delivery (CI/CD) process through continuous response using automation that eliminates manual processes. This continuous response as part of the CI/CD chain will go beyond ensuring that an application satisfies certain defined baseline security needs to automated threat hunting that maximizes security team response accuracy. By injecting security monitoring on the code level, continuous response can happen right from development to pre-production to the ongoing use life cycle. When this is done right, responding to security vulnerabilities becomes easier during each step of the process, reducing the time taken to fix or mitigate vulnerabilities.

    DevOps Will Transition from Reactive to Predictive Security Processes

    As market sophistication increases around cloud security, integration and incident lifecycle management, companies will become much more proactive at managing security within the DevOps life cycle. The need for integrating security orchestration into the development process rather than reacting to issues once a project has been deployed to production is clear based on the huge costs of reactive measures. As these platforms and tools become more available in 2018, companies will begin adjusting their DevSecOps mindset on both a cultural as well as products level to create a more holistic, inclusive process.

    We’ll See Solutions that Integrate RASP with Security Orchestration

    Having a comprehensive security solution for web applications with heightened detection, visibility and remediation capabilities will be key to response acceleration of web application vulnerabilities in 2018 and beyond. By extending security orchestration to web application security, developers and security teams will be capable of closing the interoperability gap. The key will be an increased visibility into the application and context of which attacks are happening by protecting web applications and API services in real time.

    Integrated solutions will enable users to design and deploy custom security rulesets based on the rich data derived from analytics to improve RASP solutions through expanded orchestration capabilities. The result will be a much-improved web application security layer capable of identifying and isolating active attackers, separating breaches from attack attempts and creating and enforcing active protection policies for better application protection. This ability to respond to escalating web-based attacks will eliminate days, weeks and months of manual tasks.

    — Rishi Bhargava

  • VC Predicts Major Shift to AI-Infused Applications in 2018

    VC Predicts Major Shift to AI-Infused Applications in 2018

    Thanks to the rise of artificial intelligence (AI), the nature of DevOps is about to change as developers spend less time writing code in favor of training models based on various types of algorithms to accomplish a task.

    Dan Scholnick, general partner with Trinity Ventures, an early investor in companies such as New Relic and Docker Inc., says developers in 2018 will absolutely be required to gain mastery over how to implement machine and deep learning algorithms to stay relevant. Once a model based on those algorithms is incorporated into an application, the challenge for the DevOps team will be implementing the processes needed to make sure the AI created based on those models remains tuned and optimized to the business process it’s supposed to drive.

    Now that the price of cloud services based on graphical processor units (GPUs) has dropped and open source tools for building AI models such as TensorFlow are readily available, Scholnick says the cost of infusing AI models into applications has dropped considerably. Before the end the end of the year, most users of business-to-business (B2B) applications will expect that application to exhibit many of same natural language and speech recognition capabilities that already are becoming commonplace in many consumer applications, he says.

    Serverless computing frameworks also will make it easier to scale those applications up and down as needed using event-driven architectures. Most instances of serverless computing, such as AWS Lambda on the Amazon Web Services (AWS), are employed on a public cloud. But as serverless computing becomes more common, Scholnick says Trinity Ventures is expecting competition for workloads among cloud service providers to become fierce as IT organizations continue to shy away from proprietary technologies.

    Scholnick says the rise of serverless computing doesn’t necessarily means batch-oriented applications will disappear. But it does mean that a much higher percentage of the applications being built will be either real time or near real-time.

    The challenge most organizations will face building these applications is not necessarily developing them, as the tools needed to infuse AI into applications are themselves becoming more automated. The challenge will be in collecting enough data to inform the AI model. Most of the algorithms being employed to build AI applications are decades old; the only thing that has really changed is the cost of acquiring all the data required to drive those algorithms—it has dropped substantially, thanks primarily to the rise of cloud computing. Because of those lower costs, DevOps teams can expect that not only will new applications be infused with AI capabilities, but also there will be a significant effort to modernize or replace legacy applications.

    At this juncture it’s not at all clear that DevOps teams are prepared to incorporate AI technologies into application development processes. But pressure to accomplish that goal is about to  increase: A new market research report published by Tractica forecasts that annual worldwide AI software revenue will increase in 2016 to $89.8 billion by 2025 from $3.2 billion in 2016. Most of that growth will be driven by 266 AI use cases distributed across 29 industries, according to Tractica. Whatever the outcome, however, the DevOps landscape in 2018 is about to transformed utterly once again.

    — Mike Vizard