devopsy.kinsta.cloud

Category: DevOps Practice

  • DevOps’ Role in Developing a Robust and Secure IoT Framework

    DevOps’ Role in Developing a Robust and Secure IoT Framework

    Creating a secure IoT infrastructure is a challenge for developers, requiring a holistic approach. It requires a dynamic framework that is capable of collecting data from a cloud back end as well as directly from the embedded hardware.

    Supporting this secure environment is another challenge, requiring the development of complex systems capable of deployment in a timely and cost-effective manner. This is where the relationship between DevOps and IoT proves invaluable.

    In this article, we will take a close look at how DevOps adds value to the development of a robust IoT framework. We also will examine ways in which DevOps can help in creating a secure and efficient framework for IoT app development.

    DevOps and IoT Framework

    DevOps, with its focus on reducing delivery cycle times, can increase the speed at which IoT systems can be integrated and function in a seamless and secure manner. Seamless integration can be achieved through a combination of secure app development and operational quality assurance checks.

    The DevOps methodology is rooted in the agile philosophy, which attempts to bridge the gap between different technical roles that traditionally worked in silos within the same department in IoT app development.

    Using the right tools and practices, DevOps can help in creating a framework for IoT that can overcome challenges relating to the large-scale app deployment. It can help in infrastructure positioning and monitoring. Companies that have adopted DevOps methodology have reported a 38 percent increase in growth due to additional revenue sources.

    Let’s take a look at some of the ways the DevOps framework can create a secure and robust environment for IoT app development resulting in increased productivity and revenues.

    Application Reliability and Efficiency

    One of the main functions for DevOps is to improve application reliability and efficiency—there is less need for coding and increased focus on rule-based automated configuration of key connected components. With DevOps, the app development team can identify red flags and improve operational excellence. With monitoring tools such as Log-entries, Nagios and Icinga, the team can use DevOps processes to remove latency and develop an efficient and robust IoT infrastructure.

    DevOps comes with source code control of the software applications that execute in the data center. This means developers have access to the source code, which makes their job easier. The source code reduces the complexity caused by cloud connectivity, automation and virtualization.

    Applications deployed through DevOps recover 96 times faster from failures and reported to have 440 times faster lead time for changes. Deeper collaboration between operations, quality assurance and development teams result in an ongoing feedback that helps increase IoT application reliability.

    Security by Design

    An important component of DevOps is security by design, which helps improve the security of connected systems in a DevOps environment. In security by design, the system allows continuous security testing in real time, which helps improve the security of devices connected in a network.

    The security-by design approach also formalizes security controls and implements them at each stage of the IT operations. As a result, software developers can spend time efficiently developing security controls in a consistent way instead of manually building and patching individual scripts.

    The DevOps approach to IoT application development can also help in gaining insights into the usage and performance, which can help in further refinement of the design delivery pipelines. This will lead to improved security and quality architecture of IoT environment.

    Faster Release Cycles

    Around 21 percent of respondents in a survey of 300 senior managers had stated that DevOps integration increasingly lead to meeting application delivery deadlines. The DevOps metrics lead time is used to measure how quickly the app is deployed after starting work.

    DevOps integration with IoT will result in the following benefits:

    • Developers can work on different components of an application simultaneously, which allows faster completion of activities.
    • Quick release cycles allow IoT apps to be pushed live without much delay.
    • Fast release cycles enable the app development team to build IoT applications using separately deployable services that lead to quality app deployment.

    Continuous Integration and Continuous Delivery (CI/CD)

    DevOps framework helps overcome interoperability problem related to IoT app deployment and operations. Most systems required for IoT app integration are already running in the framework that helps in quick deployment. Businesses can choose the process to automate from staging to production using tools such as Jenkins, GitLab and TeamCity. CI/CD allows developers to respond more quickly to market demands by proactively monitoring the processes.

    The approach results in faster resolution time and release of quality IoT application. Research by CA Technologies found that organizations that adopt DevOps find 21 percent increase in software delivery and 18 percent reduction in time to market due to an efficient CI/CD pipeline.

    Infrastructure Automation

    Infrastructure automation save systems administrators and IT resources time on manual tasks and remove the possibilities for human error during IT configuration, patch management and performance tracking. By scripting almost every command, developers can significantly reduce input requirement of administrators. Increased automation also provides stability as the system is no longer prone to human error on input. Repetitive tasks are a prime candidate for automation, as these are the most likely areas where people make mistakes.

    DevOps methodology makes it possible to automate the infrastructure in multiple cloud platforms. For this purpose, developers can use tools such as Spinnaker and Terraform. Terraform is useful for defining and managing the DevOps infrastructure, while Spinnaker is more useful for managing the infrastructure after code release and deployment workflows.

    DevOps framework also helps automates allocation, de-allocation and monitoring of both cellular and cloud resources, which ensures quality of service (QoS) for applications that control connected devices.

    Effective Validation

    Using endpoint validation can help in evaluating how data flows between different components. Testing of the components in the DevOps environment is done using scripts written in Python, Go or Groovy. The infrastructure testing involves stimulating the environment to test security and other components of the IoT app.

    The app development team also can make use of infrastructure as code to test configuration and environment automation. The configuration is tested using tools such as Chef, Ansible and Puppet. In addition, virtualization tools such as Vagrant or container technology can be used to test the environment automation.

    A Comparison of IoT with and without DevOps

    IoT with DevOps

    IoT without DevOps
    1. Implementing DevOps framework to IoT app development results in 21 % reduced security risk.

    2. DevOps can lead to faster deployment of IoT apps. The updates to IoT apps can be deployed every few days, and even many times in a day.

    3. IoT apps with DevOps practices can result in shorter lead time due to the reduced complexity of the development systems.

    4. With DevOps, the IoT application development team has reported a 51% increase in productivity.

    		 1. 71 % of respondents have said that security breach is a large challenge for IoT development outside of DevOps framework.

    2. Lack of DevOps can prevent fast feedback mechanism.

    3. Without DevOps, lead times can be longer. This will result in time and cost inefficiencies.

    4. IoT app development without DevOps presents productivity issues. There are few standards for app development and deployment that results in decreased productivity of the team.

    Conclusion

    DevOps tools and practices help businesses achieve efficiency when it comes to IoT app development. DevOps improve the validation of automated processes across multiple cloud vendors in a secure environment.

    Looking forward, DevOps integration with IoT will become increasingly popular as it can reduce costs and improve revenues significantly for app developers.

    — Subramonian

  • Hunting Down the Mythical High-Quality Code

    Hunting Down the Mythical High-Quality Code

    The definition of high-quality code is hard to pin down. Depending on who you talk to, there are a lot of different theories on what makes code good or bad. Sometimes, this line is blurry, and that’s why hunting down the mythical high-quality code is a complicated process. Most importantly, how can you define high-quality code? This guide will share a strong definition of what makes high-quality code, as well as valuable tips for ensuring you find it in your own work and the work of others.

    Created by GraphiqaStock – Freepik.com

    Defining High-Quality Code

    While it’s impossible to find a single definition of high-quality code that every developer of all time can agree on, we can all agree on a few key things. First, the code needs to be correct to be considered quality. Next, it needs to be capable of handling error and different exceptional situations. How will the program react in an error situation? Finally, how maintainable is the code? Will it take time to change over time or is it something that has a long lifetime? These three things form the foundation for any high-quality code, so let’s break them down.

    Code Correctness

    The most common thing to look for when evaluating whether a code is high-quality is if the code is correct. Does it perform its intended function? If you’re creating a function that creates a new user account, you’ll need to have a function which creates a new entry in the account database, for instance, as well as follow-up actions. Do all of these steps work correctly?

    When reviewing code correctness, it’s important to look for correctness in terms of this particular code function. Many types of code functions can serve different purposes depending on the situation. Testing the process or application is a clear way to analyze correctness.

    Error Management

    The next code quality is error management. Error situations are inevitable, but the right error management can prevent small problems from corrupting an entire application. Will the program instance fail on its own or will it continue to corrupt other data? Also important is how the error will be logged within the system.

    To review error management, you can perform a series of actions to try to reveal any potential errors. From there, you’ll be able to find an error trace (or lack thereof) within the project’s log. What context is included within error reports? How are these messages revealed, and how will developers debug any code? How does the application or program manage current errors? Does it shut down or does it return an error report? Errors happen, but they can be embarrassing, especially when users are on the other end. Solid error management is essential to any high-quality code.

    Code Maintainability

    Finally, the more a code is able to be maintained, the easier it will be to grow as needed. Bringing new developers onto a new project is impossible is the code isn’t maintainable. How will the code be used in the future? Ask these questions when reviewing the code to ensure it’s easy to maintain in the long run.

    Consider the following elements when looking into maintainability:

    • Class and File Structure: Are things saved in the right files and the correct format?
    • Function Naming: Are functions named in the style of the source code? It’s common to follow the already established style to be consistent.
    • Use: All the classes, modules, and variables included in the code are actually in use.
    • Comments: How many comments are included in your code and do these comments follow pre-established style?

    Now that you understand the three aspects that form the foundation of quality code, you’re ready to learn how to review code! While many developers believe you’re unable to review your own code, there really is no right or wrong, as long as you have a strong system. Let’s continue to explore the best ways to review code!

    Created by Iconicbestiary – Freepik.com

    Reviewing Code

    How do you review code for the qualities above? There is a lot of disagreement among developers over whether it’s best to have a third party review your code or if you can review your code yourself. This is up to personal preference, but you should keep several tips in mind when reviewing code. Follow these tips to be efficient and effective with your review process.

    Break the Code into Chunks

    Always review small chunks at a time. Go function by function to avoid missing any small errors. Going slow helps you keep the context of each new function fresh in your mind. Don’t try to tackle more than three functions in a sitting, since you’re likely to lose focus. Take a break before reviewing another chunk of code.

    Take a Break

    Whether you’re reviewing someone else’s code or your own, take a break. Image your code like laundry. You need to hang it out on the line a bit before it can dry. When you’re actively working on it, you are too close to see any errors. Taking a break to grab a coffee, go for a walk or even just look at the sky is a great way to return with a fresh mind.

    Save Your Edits

    Avoid fixing issues while you’re reviewing. If you’re attempting to both write code and review code at the same time, mistakes are likely to happen. Instead, take accurate notes on your comments and questions while reviewing to look back with later.

    Automated Checkers

    While you shouldn’t rely completely on automated code checkers, they can be a great supplemental resource. Performance monitors can help you avoid errors and track performance over time.

    Remember, there is no single correct way to review your own code or someone else’s. Remember the criteria for high-quality code, and find a way to find it that works for you. Raising the quality of your code and others’ code takes time and practice. Adapt the tips above as needed to create a system that works for you.

    — Wendy Dessler

  • TechRepublic’s Bombshell Survey: A DevOps Fiasco?

    TechRepublic’s Bombshell Survey: A DevOps Fiasco?

    This month, I chose to share the findings of a TechRepublic’s recent survey on DevOps not only because it’s a bombshell within the IT community, but because it brings out two eye-opening facts:

    1. Seventy-eight percent of organizations haven’t fully implemented DevOps because “they don’t get it”
    2. Only 22 percent of organizations have merged their teams for managing infrastructure, operations and development

    In other words, the message underneath is, “You must consider most DevOps success stories with a pinch of salt.”

    The big question is, Why are all these DevOps implementation failures happening? That’s where I bring the answers most experts, including renowned thought leaders, for some reason won’t give you.

    The findings of this vital survey shouldn’t leave you indifferent. Your company’s survival and growth depend on them. They’re recurrently raised in all the conferences and workshops I give. “We deployed the automation toolchain; honestly, I don’t see the business value,” or “Making the business, development, testing and operations work together is an impossible challenge,” is all I hear all the time. The last time I had to address these complaints was at the Econocom’s DevOps Seminar in Toulouse, France.

    The answers I provide result in the same reactions: Companies successfully change their DevOps vision and implementation approach.

    Believe it or not, that’s my six-year experience advising on DevOps worldwide, as well as the observations of an increasing number of reliable IT industry analysts including Joe McKendrick and Jason Bloomberg. The three fundamental failure factors of DevOps implementation are:

    1. Either a lack of or unclear business objectives.
    2. Widespread misconceptions of DevOps including among thought leaders.
    3. Conflicting interests of the DevOps tools business.

    Let me give you a few ideas that will either help you monetize your organization’s transition to DevOps or adjust your existing DevOps capability and make it profitable.

    Unclear Business Objectives Result in Irrelevant DevOps Capabilities

    Again, that’s my experience and the observations of many IT industry analysts, most DevOps initiatives are disconnected from any business objectives.

    In all the workshops I conduct, the question, “What’s your business goal?” gets the same blurry answers: “Adopting DevOps is a must,”  “We must automate our IT processes,”  “Making our IT agile will make our business competitive,” “Speeding up delivery is a competitive advantage our business lines will like,” and “Automating our IT processes will do good to the business.”

    What you must know is, these goals range from vague and fake to inappropriate and nonexistent. They primarily serve the IT department’s interests. Not the business.

    The fact is, there’s a significant gap between business line expectations and the DevOps benefits as imagined by your IT leader peers and their associated vendors. The business looks to meet the challenges of the disrupted markets created by Google, Amazon, Facebook and Apple (GAFA, in the rest of the article)—competition which includes continuous innovation, accelerated time-to-revenue, cost reduction, low prices and market responsiveness. And the only help DevOps experts offer is the acceleration of applications delivery and the automation of IT operations. Is it enough? The answer is clearly no; it’s a drop in the ocean.

    The GAFA are disrupting your company’s markets. The only chance to resist them is to adjust your business model to the new competitive constraints. Because they didn’t transform as their disrupted markets required, Nine West Holdings, the Bon-Ton Stores, Toys R Us, Remington, Southeastern Grocers and Tops Markets were all kicked out of business. Read what Business Insider’s Hailey Peterson said about it in a recent article.

    I encourage you to involve your business lines in your DevOps project and agree with them on a clear business objective. Then, implement DevOps to enable that objective. Otherwise, that’s wasted time and more importantly, wasted investment!

    The Secret of DevOps Has Always Been About How Well You Work, not Technology

    This is something I hope you won’t doubt: Most experts including renowned thought leaders play on words to present DevOps as close to either an agile software development framework or a continuous delivery infrastructure (CDI). Let’s say it straight: That vision, now adopted by CIOs, is erroneous and has been taking thousands of businesses into the wall.

    Adam Jacob’s article, “The Secret of DevOps, It’s Always Been About People, Not Technology,” provides from my perspective, the best definition of DevOps. It presents it primarily as, “… fundamentally about taking the behaviors and beliefs that draw us together as people, combining them with a deep understanding of our customers’ needs, and using that knowledge to ship better products to our customers.” But he makes it clear, “Tools matter. Make no mistake, trying to change the way you work without changing the mechanisms by which you do that work is a futile exercise in excruciating failure. But tools exist in service of the prime directive: building highly functioning, highly effective cross-functional teams, that attack your thorniest business problems as a unit, rather than as lone individuals or silos with competing incentives.”

    What’s interesting with Jacob’s big picture is, it’s definitely business-oriented and takes into account value creation drivers such as the human factor, values and behaviors, processes and practices, cross-functional collaboration and, of course, technology. Every qualified IT leader should understand these drivers as the fundamentals of their company’s survival and growth.

    So, shrinking DevOps to agile software development and Jenkins, Puppet and Docker, and thinking it will result in revenue doesn’t make sense. That’s the reason why the 78 percent of organizations in the TechRepublic’s survey failed!

    Would you agree that to set up a profitable business, the most important thing is to deploy Jenkins, Chef, Docker? I hope not!

    DevOps is about how well you mobilize your company’s assets— staff and skills, values and behaviors, processes and practices, tools and infrastructure—to make it competitive and wealthy. Adopting DevOps, particularly in today’s disrupted industry context, is primarily a business transformation effort. Nothing else!

    If you don’t want to be part of the 88 percent of organizations that proved unable to merge their team for managing infrastructure, operations and development, like Adam Jacob’s article suggests it, tackle DevOps primarily as an agile business operational model. Otherwise, get ready to be among the next GAFA victims!

    Preventing the Next DevOps Fiasco

    I’m afraid the conditions for the next DevOps fiasco are in place. They have a name: The incredible power of IT vendors.

    The incredible power of IT vendors relates to what Harvard’s strategist Michael Porter calls the “bargaining power of suppliers.” It’s the market or industry configuration where the domination of one company or a group of companies reaches a point where they can impose their views, products and services. IT vendors are exactly in that situation.

    IT tools have improved productivity so much over the last 30 years that companies have come to believe that they can fix every business problem including innovation, agility and profitability. IT vendors, using massive marketing hypes, are taking advantage of the situation to make millions of dollars. Dollars aren’t the problem; it’s the poor ROI their clients get.

    Will this TechRepublic’s survey help to prevent the next DevOps fiasco? Time will tell.

    Key Takeaways

    Your company’s priority is to survive the disrupted markets created by the GAFA. You won’t make it happen unless you definitely acknowledge that revenue, the essence of your business, is created as part of complex process that mobilizes across your company’s value chain, your staff and skills, values and behaviors, processes and practices and, of course, tools and infrastructure.

    If DevOps can’t help businesses with what matters right now—survive their industry disruptions— it’s definitely useless!

    As Chris Tozzi, suggests it, “The other main possibility for the post-DevOps world is that we’ll see DevOps extended into more and more parts of the business that are not directly related to the two core areas of DevOps practice, development and operations.”

    Here’s a resource that tells you all about how to implement DevOps as the catalyst of your business competitiveness: “How to Yield Business Benefits with DevOps.”

    — Philippe Abdoulaye

  • DevOps Adoption: The Driving Force of the Industry

    DevOps Adoption: The Driving Force of the Industry

    DevOps has transformed from a mere idea on paper to the way processes function in the face of an immediate requirement. Development and Operations together make for one of the most successful collaborations today.

    As per a research report, people have now begun to understand what DevOps is. When asked how familiar they were with DevOps, 84 percent of respondents said that they well-versed with the concept, in comparison with 60 percent who agreed to the same the previous year.

    DevOps is writing the success stories of the world’s business giants. Facebook, Google, Twitter and Amazon are all working the “DevOps way.” All falls in place when these companies develop, test and successfully deploy code in a matter of one to 23,000 minutes per day. We agree that’s insane!

    How Have We Benefited from DevOps Adoption?

    To sum up the benefits of DevOps adoption in a nutshell, users see:

    • Drastic reduction in lead times—With the pressure to deliver software faster and meet the challenges of the growing market, there is always a need to look at progressive ways of getting the job done, DevOps became the solution. As per statistics, practitioners believe this to be the top benefit of DevOps in 2018. Sixty-nine percent of respondents agreed to this benefit, as compared to 39 percent in 2017.
    • Increased ability to release new features with improved reliability stability and security—The need to improve the user experience and keep the customer equipped with the necessary tools to meet the challenges of a growing business made IT personnel realize that it is always essential to introduce new features into the deployment process. DevOps made it easy. Figures tell us that the implementation of DevOps led to 73 percent of people believing in its benefit of enhanced user experience, this year.
    • Enhanced IT and Organizational Productivity, Higher Profitability, Revenue and Market Shares—Now with the best process having so much to offer, all businesses have gained a lot in terms of savings and earnings. DevOps drives revenue: 26 percent of people reported an increase in revenue in the year 2018 as compared with 20 percent in 2017.

    Why No DevOps?

    Although we’ve seen a major shift in trend from being skeptical about DevOps and its implementation to becoming “pro-DevOps,” over the years, not all of us are up for this big business move. The reasons being many.

    Listed below are the most commonly given reasons by industrialists around the world:

    • Other technology and business priorities—With newer technologies being developed every few weeks, companies are confused over which technology will give their business the required leverage. This leaves them to either becoming very choosy or just ignoring the prospects of adopting a technology at all. Some business owners think about fund allocations. They want to invest their hard-earned money into something they see as more viable or something that convinces them about profits. When it comes to innovative ideas such as DevOps, they think these things may not bring them immediate results or they’re not as important as the “conceived” business priorities. As per a study conducted in February 2018, as much as 38 percent of the sample population opted out of DevOps for the above reason.
    • Lack of resources—Most organizations lack the required resources in terms of personnel, tools and persons with expertise. This discourages organizations from taking up such practices. While it is great to have a workforce with work experience for the dev and ops teams individually, it is crucial to have employees with DevOps experience on board. Similarly, lacking the right tools can have your organizations whimpering in the wake of a growing market despite having an able workforce. Statistics show that 34 percent of people hesitate to adopt DevOps for the given reason.
    • Lack of cooperation between development and operations—Whenever there is a mention of DevOps, there is also a mention of the cultural indifference of Dev and Ops teams. Each team has their unique work culture and when they come together on common ground, they cannot help but fall apart. Most organizations do not encourage the DevOps practice on account of this cultural disparity.A significant 22 percent of the industries under this research shun the idea of DevOps owing to this disparity.
    • ‘We don’t see the value’—It is likely for some business to say this. It is difficult to assess the value of the process from an outsider point of view. If someone has heard about DevOps but don’t how it will profit their businesses, then it is difficult for them to adopt it. As per statistics as small as 6 percent of the sample population did not adopt DevOps for this reason.

    On an End Note

    Organizations have been opting for DevOps after seeing its contributions to the industry. This year has most businesses functioning with major dependence on the skill and agility of the DevOps processes, and this has been proven through the success of their business. We hope the remaining number of entrepreneurs come to realize the importance of DevOps for their business and implement its benefits to build their success and keep up with the challenges of the fast-growing market.

    — Veritis

  • The Need for a Command Center in Managing Complex IT Operations

    The Need for a Command Center in Managing Complex IT Operations

    A few days ago, I was traveling from Bangalore to Mumbai. It was an overcast and wet morning so I started out early to avoid having to battle traffic and worry about the prospect of being delayed. At the airport, I checked in, went through the usual formalities and boarded the flight.  I was anticipating a delay, but to my surprise the flight was on time.

    While we were approaching the main runway, I could see many flights ahead of us in a queue, waiting for their turn to take off. At the same time, there were two planes that had landed within a couple of minutes of each other. The entire environment of the runway and the surroundings looked terribly busy. While our flight was preparing to take off, the air traffic control (ATC) tower grabbed my attention. That tall structure looked very calm in the midst of what seemed chaos, orchestrating every move of all the planes, making sure that the ground operations were smooth, error-free and efficient in difficult weather conditions.

    I started comparing the runway and airport ground operations with that of the complex IT environment in enterprises today, and the challenges it poses to the IT operations teams. Today, critical business services reside on complex IT infrastructure such as on-premises, cloud and hybrid cloud environments. These require security, scalability and continuous monitoring. But do they have the ATC or the command center that can orchestrate and monitor all the IT assets and infrastructure for its smooth functioning? For instance, if the payment service of an e-commerce service provider is down for few minutes, it would have to incur significant losses and impact overall business opportunities creating an adverse impact.

    Perhaps, today’s IT operations team needs one such command center, just like an ATC at the airport, so that they can fight downtime, eliminate irrelevant noise in operations and provide critical remediation. This command center should have the ability to provide a 360-degree view of the health of the IT infrastructure and availability of business services besides providing the topology view of dependent node structure. This could help in assessing the root cause analysis of a particular IT incident or event occurrence. The command center should also provide a complete view of all IT assets, aggregated alerts, outage history and past incident occurrence and related communication, enabling the IT team to predict the future occurrence of such events or incidents to prevent the outages of critical business services. In case these outages or incidents did occur, it would be a boon for the IT operations team if a command center could provide critical data-driven insights and suggest remedial actions, which in turn could be provisioned with proactive BOTs.

    I arrived at my destination on time, thanks to the ATC, which made it possible, despite the challenging and complex weather conditions. This brings me to a critical question that I need to ask: Do you have the required ATC or command center for IT operations to help you sustain, pre-empt and continue with business operations in a complex IT environment?

    — Neeraj Deuskar

  • DOES UK: Nike Applies ‘Just Do It’ Attitude to DevOps

    DOES UK: Nike Applies ‘Just Do It’ Attitude to DevOps

    Nike’s DevOps transformation has had a lasting impact on its culture and productivity, while allowing the company to connect with its customer in ways it never could before. Its journey down the path to DevOps was shared at the DevOps Enterprise Summit (DOES UK) 2018,  in London.

    For a company of its size and success in the current market to take a giant leap of faith and come out even more successful takes incredible courage, hard work and collaboration. But that’s Nike for you: Shoes, apparel or DevOps—it doesn’t make a difference to the company. From day 1, Nike has lived its mantra, “Just Do It!”

    Imagine this: You’re a high-level IT employee at a non-technology-focused company with a market value of just over $110 billion. All of a sudden, the newly appointed CEO makes the most significant announcement in recent history of the company, essentially saying, “We are entering a new era of growth and we expect to use technology as our main way of getting closer to the customer.” Pretty crazy, huh?

    This was reality for Randy Lyons, a longtime employee at Nike with an extremely strong taste for competition and the opportunity of a lifetime in his hands. Based in the EMEA region, Lyons teamed with global Nike CFO Michelle Power with one goal in mind: to bring customers closer to the products, available at any of their 7,000 branded stores globally, through a digital platform. The aim was to tap into consumers’ need to check our phones before making a purchase. The scale was momentous; arguably, larger than any other company achieving a successful DevOps or Agile transformation before. To pull this off on the scale CEO Mark Parker had intended, a complete culture shift was necessary.

    Luckily, the unlikely team shared the motto, “Culture eats strategy for breakfast,” and they were eager for the challenge. To start, they needed to change the self-identity of the IT branch. For too long had the underutilized IT staff heard the narrative that “technology helps the business succeed,” rather than existing as a part of the business. Lyons and Power placed a heavy emphasis on the new role of cross-functional IT teams as an integral part of the company rather than a useful helper. They adopted the hashtag “#OneTeam,” which promoted interaction and alignment of the tech team with all other teams, and showed everyone working for them that they were fully invested and energized in positively changing the culture and structural hierarchy of Nike. Additionally, they sought to point out the impact each person’s work was playing through the lens of the overall strategy. The “How is what I’m working on going to effect the direction of this company?” question versus “What else do you need me to do?” was a significant change—it boosted the overall motivation of the teams to work together and even raised individual production significantly.

    However, the transformation was only beginning. Early on Power and Lyons discovered a fundamental flaw in the company they sought to transform: Their employees didn’t feel rewarded for their work. While it might be easy for some companies to blow off this issue in favor of dealing with “bigger” issues, they wanted to promote a company culture that would foster growth and speed, which would not—or could not—happen unless their teams felt beyond satisfied with their workplace environment. So, instead of the annual award ceremony Nike regularly used to reward and congratulate its employees, Lyons and Power decided to implement a simple change they felt would satisfy everyone: They added 15 minutes to the end of their weekly Friday staff meeting to give shout-outs everyone who had performed above expectations on a project. It was awkward at first, Lyons admitted. He also described it as “quite American” (ha ha)! However, this simple idea created a complete culture shift. Suddenly, the tech team was being praised by the supply team, while the supply team was being praised by the sales team, and the sales team was being praised by the tech team. This weekly validation of a job well done turned into more jobs well done!

    Ultimately, the agile teams were motivated enough and aligned in such an efficient way that they were able to produce five separate software systems fully integrated into a single one-member profile:

    1. com (full selection of products sold in store)
    2. Nike app (for a more personalized experience)
    3. Sneakers (collection of shoes sold in store)
    4. NRC (for running products)
    5. NTC (for training products)

    These software products were incredibly effective in creating an emotional attachment with the brand and the products. Finally, the goal of getting the customer closer to the product through a digital interface had been achieved. The process to get there wasn’t easy. There were many problems to overcome and many things that changed drastically to allow for a newer and more efficient way of doing things. However, Lyons noted this transformation was the most influential on a personal level for him: Before undertaking this project, he didn’t feel as though he could effectively serve as both a team leader and participant. He could easily take orders and sometimes give them out, but it wasn’t until he partnered with Power that he learned to become a not just a team player, but the best player on his team.

    The DevOps journey was a transformational process for both the company and the people involved. Today, “Just Do It” means exponentially more to Nike than just a slogan—it’s a way of adding value and efficiency to business.

    This was just one of many of great presentations at this years DevOps Enterprise Summit UK this past week. We will be highlighting others in the days ahead.

    — Landon Shimel

  • Developer Trend Chat: Microservices, Node.js, Kubernetes

    Developer Trend Chat: Microservices, Node.js, Kubernetes

    The role of software developers has never been more important. Developers touch almost every corner of our lives, from health care and retail to education. It’s an extremely rewarding career—so much so that software development is now ranked the Best Job in the United States.

    The nature of software development demands that developers be fast-moving. New tools and technologies are providing developers the ability to adopt new skills, work faster and reshape how they work. In this Q&A, CEO of LunchBadger Al Tsang discusses trends in software development.

    Q: Data distribution is still a difficult and complex aspect of breaking down a monolithic architecture. How can enterprise architects avoid this or what is a good strategy for dealing with this snag when they will encounter it eventually?

    Al Tsang, CEO, LunchBadger

    Al: The data’s location, its dependencies and varying levels of data normalization, make breaking down monolithic architectures a challenge. Microservices initiatives can address these challenges by constructing a comprehensive data model. In the past, we had UML tools such as ERD diagrams. These tools are not as common anymore, however, the practice of what they represent still brings value in understanding what data your applications currently use, what’s obsolete, what’s redundant, and what’s related with dependencies.

    Microservices and the tie in to data should be atomic enough so that the data that it operates against is wholly owned and contained. This is easier said than done. There are often dividing lines that can be carved out that mirror the business functionality itself—whether that be by domain, by entity or by business process. In some cases, it’s a combination of all the above.

    Q: Why do you think serverless and FaaS (functions as a service) is growing at such a rapid rate and what specific pain points do serverless platforms (such as LunchBadger) address?

    Al: I believe serverless and FaaS is growing rapidly for a number of key reasons:

    (1) Infrastructure and application platform [are] becoming highly commoditized where a developer can pass the buck to have operational concerns placed on a third party.

    (2) The pressure and need to innovate requires an intense focus on working on your core IP as a differentiator while everything else in your code is a supporting role and oftentimes something that is completely boilerplate (e.g. think persistence to a database or NoSQL data source).

    (3) The movement and drive behind attaining microservices means getting down to bite-sized pieces of functionality means whittling down your logic do distinct reusable compartmentalized pieces of code—i.e., functions—and “serverless” fits this paradigm nicely by adding that you should only concern yourself with the piece of code on an event driven basis.

    (4) New and old companies alike have amassed a zoo of technological languages and platforms where skill sets and resources can be more efficiently utilized if you have a common runtime paradigm and can write your business functionality that supports polyglot usage.

    Q: According to a survey in 2017, Node.js was primarily used as back-end infrastructure for APIs. One of the main strengths of Node.js is that you can use the same language on the entire stack. How do you think Express.js and other minimal frameworks like it contribute to its popularity and why?

    Al: One reason Node.js has had rapid and wide adoption is because it is a massive equalizer. Node.js developers don’t need to have ninja-level domain expertise in high scalability, multi-concurrent connectivity, threads or similar complex topics just to be able to build a scalable app.

    Node.js takes advantage of a language that had the principles of high scalability built inside, namely evented asynchronous programming. Node.js also has an advantage as it’s the language that any web developer would have exposure to thanks to the ubiquity of browsers. Moving the same language and its strengths to the server was a huge win for folks to truly become “full stack.”

    Express.js has further contributed to Node.js’ success by adding the basics of web utility to Node.js. Every web application needs a web/app server that exposes URLs as routes. All servers have consumers making requests and processing those requests can often time be chained from one piece of logic to another. Express took the learnings from Ruby and Sinatra and brought them to Node.js.  You scaffolded a template project and filled in the blanks, as needed and where needed. It’s highly productive because the starting point for many web applications follow this same model.

    Express Gateway galvanizes the success of Express.js—its rich ecosystem of middleware modules and ubiquitous understanding among many developers and make its cloud ready and cloud native by separating out the configuration, metadata and conditionality to be declarative and dynamic. By doing this, Express Gateway runs in containers and orchestrators in a distributed way without worrying about being coupled at any given tier of the application.

    Q: Node.js and Kubernetes is a popular combination, but many developers and companies are confused on where to start or how it will affect their tech stack. Can you explain the top roadblocks you’re seeing and how companies can overcome them?

    Al: Roadblock #1: Where should you extend Kubernetes or where should you extend your Node.js application?

    I think this entangled mess is actually not as bad as it’s often perceived it to be. If it’s a core part of your application and you’ve written it in Node.js, then it should be completely independent of where and how you run it. Before the wide adoption of containers, many Node.js applications were being run in process managers. Many are still running in process managers within a container. In short, if it’s a core piece of your application logic, it should be in Node.js. If it concerns how and where you run the application logic, now you’re looking at configuration or extensions within Kubernetes.

    Roadblock #2: Should I use Node.js to orchestrate my application or leave that to Kubernetes and why?

    Orchestration means wiring up your application at the infrastructure level. Leave this piece to Kubernetes, which can expose and manage your microservices truly as “services.” When you’re writing Node.js applications, you shouldn’t have to worry about the “I/O” of how different Node.js processes interoperate. The whole premise behind microservices is that there are distinct lines drawn where processes must interoperate without assuming the other process may even be up and running.

    Roadblock #3: What if I have a component that has both infrastructure AND application concerns?

    This is a tough one where a lot of companies, large and small, are feeling pain. Kubernetes has a notion of an ingress controller, which is really nothing more than routing and exposure of requests externally to a resource designated internally to handle it somewhere with the Kubernetes cluster. This raises the question: Should you put application-level concerns on that ingress controller?

    I believe in a clean separation of concerns, even if that means having some runtime overhead. If your business requirements don’t require super low latency or other cases that drive you to blur the lines between infrastructure and application, then it’s much easier to maintain if there is a clean separation. This is really no different than slicing and dicing your application into smaller microservices. It’s just executed in your stack at a horizontal rather than vertical level. Build an ingress controller that is only concerned about routing to the right resource. Then build a separate API gateway that sits in front of the microservice(s) to take care of application-level concerns.

    — Malia Powers

  • Integrating Blockchain and DevOps

    Integrating Blockchain and DevOps

    Blockchain is one of today’s hottest technology buzzwords. And at the same time, the concept of DevOps has achieved acceptance and is gaining momentum. Blockchain and DevOps already offer a number of benefits individually. Together, they can provide significant tactical and strategic advantages. However, some challenges must be overcome simply to adopt blockchain, as well as to successfully merge blockchain and DevOps.

    What is Blockchain?

    Let’s start with an overview of blockchain. Many people mistakenly conflate cryptocurrency and blockchain, because many of the key features of cryptocurrency are a function of blockchain. But blockchain is a separate and unique concept that has applications and benefits far beyond cryptocurrency.

    Blockchain is a distributed account ledger, the use of which enables data to be processed and stored securely. Blockchain relies on three core concepts—peer-to-peer networks, public-key cryptography and distributed consensus that is based on the resolution of a random mathematical challenge. Reliance on these three concepts allows blockchain transactions to be secure and relatively anonymous. Every transaction is recorded in the ledger as a data block that is appended to the end of the chain of previous transactions. No group or individual owns or controls the ledger, and all parties can view the chain of transactions, ensuring transparency and integrity.

    A number of key features make blockchain attractive. Data is validated across all participating nodes, which eliminates the need to reconcile transactions. The use of distributed consensus provides a high degree of confidence, but transactions in the chain also can be verified easily. Blockchains are immutable—new data can be appended, but blocks of data already in the chain cannot be modified or removed. Finally, blockchain reduces costs and improves the efficiency of processing transactions and storing data due to its decentralized architecture.

    The challenge facing organizations wanting to adopt blockchain, however, is how to incorporate it seamlessly with DevOps development processes and culture.

    DevOps for Blockchain Development

    Organizations need to address challenges in three major areas to take advantage of blockchain: culture, process and tools.

    On the culture front, the success of blockchain depends on support at the executive level as well as adequate budget and resources for proper implementation. If you can’t find champions within the organization to drive the blockchain cause, your project is doomed before it starts.

    Whether you’re building a blockchain within a single company or a blockchain network that includes nodes outside your organization, obtaining widespread agreement on the technology and blockchain processes can be an issue. The absence of widespread industry adoption or any sort of standardized tools or processes adds complexity.

    Finding the right talent can also be a problem—and once you find it, you may have to pay a premium to obtain it. According to a recent article in TechCrunch, “Blockchain-related jobs are the second-fastest growing in today’s labor market; there are now 14 job openings for every one blockchain developer.”

    From a process perspective, blockchain is an emerging concept that lacks mature management principles or design standards. The process framework, and the different roles involved, are still unclear. Most organizations lack expertise concerning the blockchain application stack and environment; in addition, the metrics that should be monitored to measure efficiency and performance are not yet well-defined.

    The absence of development tools is another major hurdle for blockchain. The developer tools currently available for the blockchain ecosystem are unreliable. The blockchain ecosystem still needs an integrated development environment with good linters and plug-ins, a build tool and compiler, a deployment tool, documentation, testing frameworks, debugging tools, logging tools, security auditing and analytics. While some versions of these tools exist, they are not yet adequate to meet the needs of blockchain developers.

    It is also important to understand that, although many blockchain implementations are based on open source technology, blockchain isn’t free. Keeping track of transactions requires hardware, networking bandwidth, electricity and processing power. Because a blockchain ledger is distributed, transactions aren’t just processed once—they are processed on every node in the blockchain network. As a trusted network grows, the associated costs skyrocket. These expenses can be a barrier that prevents smaller organizations from experimenting with the technology.

    Integrating Security into DevOps

    If you are thinking about implementing blockchain, some of the core principles of DevOps—specifically DevSecOps—come in handy. DevOps is built on the concept of breaking down silos within an organization and enabling each team and individual to take responsibility for the project as a whole, rather than separating tasks by role.

    To implement blockchain successfully, you need a system that rewards innovation and supports teams of individuals who work together to address any issues. Integrating DevOps and security fosters stronger application security throughout the software development life cycle and helps with blockchain development efforts as well.

    The shift-left philosophy and the push for automation are DevOps principles that also will serve you well with blockchain. Integrating security earlier in the life cycle—shifting left—and incorporating automated security testing and security bug tracking are essential. The blockchain network needs to be tested for performance and latency, which will vary depending on the size of the network, the expected transaction size, the consensus protocol used and the associated required latencies. It is also important to determine whether the integrity of the network and the shared blockchain ledger is maintained while testing throughput.

    To maximize efficiency and productivity, put processes in place that allow you to consistently monitor and adjust, based on feedback. Track individual and overall security vulnerabilities, the amount of time it takes to detect them, the amount of time it takes to remediate them, and other factors relevant to application security. These metrics should be visible to every individual so that each can understand and take ownership of the appropriate elements.

    Blockchain and DevOps

    Blockchain technology is poised to change the way business is conducted today due to its promises such as of secure, immutable, peer-to-peer decentralized trust networks with distributed consensus, shared account ledgers and smart contracts.

    These same advantages, however, introduce a host of additional considerations to blockchain-based applications and make for greater testing challenges. Not only is the change in technology significant, significant changes are also necessary from a business process standpoint. While blockchain applications will have to go through standard testing and validation, including functional testing, integration testing, security testing and performance testing, they also will require additional specialized testing for smart contracts and peer/node testing.

    DevOps practices can provide great value to organizations under pressure to become more customer-centric and innovation-focused. The efficiency, quality and consistency that adopting DevOps provides is exactly what is required for traditional organizations looking to embrace the leading-edge technology known as blockchain.

    — Tej Aulakh

  • Serverless Computing: Moving from DevOps to NoOps

    Serverless Computing: Moving from DevOps to NoOps

    Developers rejoice as serverless computing ushers in a new era of ‘NoOps’ to replace the ill-fitted DevOps model.

    While some organizations do better than others when it comes to implementing DevOps, almost everyone agrees it’s a concept easier penned to paper than pinned to reality. The idea of integrating development and operations is smart, but the implementation proves troublesome. A replacement option is thus largely welcomed by developers everywhere.

    Enter the new concept of NoOps, which means dropping operations from any consideration during the development cycle. It’s not that operations are being ignored; that would be a foolhardy step backward. Rather, NoOps means never having to worry about where the code runs and, thus, developers are freed from giving operations another thought.

    “Serverless computing allows users to run code without provisioning or managing any underlying system or application infrastructure, and they automatically scale to support increasing or decreasing loads,” explained Gartner serverless analyst, Arun Chandrasekaran, in a blog post.

    Amazon sparked interest in serverless computing when it announced AWS Lambda at its re:Invent conference in 2014.

    “I’d argue that the precursor to serverless computing is cloud IaaS, where the complexity of underlying resources—servers, storage and network—was hidden from the users, and with IaaS providing flexibility to provision unlimited compute, storage and network resources on-demand, Chandrasekaran said.

    Serverless: To Use a Server or Not? ‘Tis Not the Question

    Serverless computing is a developer’s dream not only because there is no longer a need to worry about where the code is going to run, but also because there is no need for direct access to the operating system to manage that code. The result: Developers can focus solely on coding—the very thing they do best!

    That statement would be easier for some to understand if it were not for the utterly confounding term “serverless.” Obviously, anything requiring computing involves servers, so saying this process is serverless is simply nonsensical. While the term is unfortunate and bordering on meaningless, the concept is solidly real and more than a little familiar.

    For all practical purposes, serverless is just another word for cloud but with a bit of a twist—pricing is based on the actual amount of resources consumed by an application, rather than on pre-purchased units of capacity.

    Deploying Code with NoOps in a Serverless Environment

    Additionally, the term “serverless code” can be used either in conjunction with code deployed in traditional styles such as microservices, e.g. loosely coupled/SOA. Or, code can be deployed in the form of full applications that can be written to require no provisioned servers.

    In serverless environments, jobs are scheduled on-demand, meaning as data comes in and is available. It can be automated so that a job runs once data is received. This means that jobs run only when data exists and otherwise sit idle, where they can’t burn resources.

    Economies of scale also completely change in serverless computing. That’s because serverless delivers the ability to put some intelligence behind when and where jobs run, so that they can be spun up and spun down as quickly and economically as possible.

    Bottom Line

    Opting for NoOps, meaning working in a serverless environment, is really a choice to be more intelligent about how resources—hardware, software and people—are being utilized. It is about cutting resource waste and associated costs, while enabling talent to focus on writing innovative code.

    No job will sit there burning resources and waiting for the data to come in. Rather, the job runs on demand, as you need it, in milliseconds and without distracting you from other tasks.

    “NoOps still requires connectivity so beef up your connectivity to your cloud providers, if you haven’t already. And you’ll eventually have to troubleshoot slow serverless functions as a ‘network problem,’” said Andrew Lerner, an analyst at Gartner in his post.

    To gain even more advantages in serverless computing, and perhaps to make up for time lost in network troubleshooting, no matter how small, look for and use reusable code everywhere you can. Drag-and-drop interfaces that enable fast use of reusable code frees developers further, so they can shorten both the development and testing cycles. Time economy is important in modern day continuous release cycles. A NoOps and reusable code strategy can dramatically improve your time and resource economies of scale.

    — Laurent Bride

  • Updating Your Skills for the Internet of Things

    Updating Your Skills for the Internet of Things

    The internet of things (IoT) is breaking rules. For example, in many cases IoT designers purposely limit the processing power and connectivity of IoT devices. Making devices with less processing power and connectivity may buck the IT trends of recent years, but IoT is changing some of the assumptions and approaches of traditional IT. IT professionals moving toward IoT will need to learn some new skills, strategies and technologies.

    IoT devices are smart (having their own embedded processor) and connected (often using wireless networks). But setting up, configuring, programming and maintaining an IoT device is very different from doing those tasks on a traditional computer. The typical IoT device is purposely configured with extremely limited processing power, memory and data communication capabilities. A device may not have a user interface other than perhaps a power button and a few LED lights. These constraints have positive effects; they make IoT devices both inexpensive to produce and downright miserly in their use of electrical energy. And IoT devices may even extract energy from the environment around them, a feat called energy harvesting. This design strategy enables devices to be located anywhere, even in remote locations where electrical power sources and connectivity may be limited.

    Sensors on IoT devices can collect a mind-boggling variety of readings, such as the temperature of frozen food in a delivery truck, the volume of traffic passing through an intersection, the quality of soil in a particular location of a farmer’s field and countless other measurements. The sheer volume of data produced by IoT devices must be processed, interpreted and handled securely. At the same time that IoT is dramatically increasing data volumes, it is also creating new challenges to keep that data secure and private.

    Real-time data processing and networking enable data to be collected, processed and acted on very quickly. Based on intelligence provided by the data, an immediate, automated response may need to be triggered. For example, the temperature in the refrigerated delivery truck may need to be adjusted. The brakes in a smart car may need to be activated to avoid a collision. Or the mix of chemicals may need to be modified as a spraying machine advances through a farmer’s field, based on soil samples taken at the sprayer’s exact geographic location. The ability to process and act upon data so quickly seems at odds with the limited power and capabilities of the typical IoT device. But special operating systems and data processing strategies enable these real-time operations to be performed efficiently.

    Edge computing provides another strategy for processing the data from IoT devices. Rather than perform all heavy processing tasks in the cloud, edge computing moves some processing tasks back to the edge—where the local network meets the cloud. This means placing some sort of heavy processing capability near the IoT devices, and using an IoT gateway to “do the heavy lifting” on behalf of IoT devices. The gateway can handle all communication with the cloud, so the IoT devices themselves can use lightweight communication protocols and (safely behind a firewall) won’t require the same security capabilities (such as heavyweight encryption processing) that they would require if they were directly connected to the internet.

    New methods of data processing and analysis are used to make sense of the massive quantities of data produced by IoT. Data analytics tools such as Azure Stream Analytics, Vitria, and Statistica are geared toward IoT. Big data and cloud storage technologies, such as Hadoop and NoSQL database systems, take on new importance with IoT.  So do more traditional skills such as SQL. Machine learning and artificial intelligence technologies will also play a critical role for processing IoT data.

    IT professionals preparing to move to IoT should consider adding some of the following skills to their portfolio:

    • Working with microcontrollers, sensors and actuators.
    • Programming real-time operations on microcontrollers.
    • Embedded device power management and deployment of energy harvesting technologies.
    • Selecting, installing and configuring real time operating systems.
    • Setting up and configuring sensor networks and IoT gateways, including communication technologies geared toward these networks, such as MQTT, 6LoWPAN, Thread and Zigbee.
    • Managing cybersecurity on embedded devices and sensor networks.
    • Working with data analytics tools, advanced SQL, cloud storage and NoSQL databases, artificial intelligence and machine learning.

    CertNexus is looking for IT professionals to take the CIoTP beta exam. The Certified IoT Practitioner is meant for those seeking vendor-neutral, cross-industry, foundational knowledge on the internet of things. If you are interested in taking the CIoTP beta exam, please email info@certnexus.com.

    — Brian Wilson