devopsy.kinsta.cloud

Category: Enterprise DevOps

  • Speaking the Language of Applications

    Speaking the Language of Applications

    I arrived early to a meeting, and the pleasant security guard at AT&T suggested I take a look at their innovation museum while I wait. Among motion picture sound technology and life-size photos of switchboard operators on roller-skates stood a transistor prototype. The transistor was invented in Bell labs in 1947, and it changed the world. Steve Wozniak considered it the greatest innovation of all time in his 2014 article.

    But almost nobody needs to think about transistors anymore. The transistor had to become transparent and abstracted, so the next generations can build great things in higher level. The transistor made a huge influence on our lives as an enabler, but if people had to keep talking about transistors it wouldn’t be possible.

    Abstracting technologies is key to advancing to a higher level, making it possible to solve real business problems.

    The language of a client-focused business is applications. If we want to make a business execute faster these days, we need to make the development and release of its applications execute faster. But one thing stands in our way: the infrastructure. Applications reside on infrastructure–they are installed on servers, bundled in containers, on cloud instances, in networks, using storage.

    If we want to speak the language of applications, we need to abstract them from the infrastructure, and make the infrastructure transparent.

    The concept of abstracting applications is what stands at the basis of every new approach to application development and release around us.

    • Containers are all about abstracting services from specific infrastructure and making them mobile.
    • Serverless takes it to the extreme.
    • Public cloud makes it easier not to worry about owning physical infrastructure.

    Technology screams, “Think applications, soon you will not have to worry about infrastructure!”

    And yet, most of us mix applications and infrastructure in an unhealthy way when we try to automate them. It is unhealthy because mixing applications and infrastructure prevents reuse of automation assets and makes it very difficult to connect infrastructure usage to a business context.

    Understanding how mixing applications and infrastructure is manifested requires looking back into the evolution of infrastructure and application automation.

    The Evolution of Infrastructure: Manual Deployment and the Inception of Its Automation

    In the beginning there was manual. We got a server; it was sitting on a shelf. We got the application artifacts, maybe on a CD or a USB stick. We installed the application on the server. Our application was ready for use. When we needed to upgrade, we went back to the shelf and installed the update on our server. It was very hard to make this operation faster.

    This is where automation of applications and infrastructure started.

     

    Behind any automation tool or standard stands a model. This model reflects how its creators originally perceived the problem they were trying to solve. It consists of the entities they defined as first-class citizens, the operations they wanted to apply on these entities, their attributes.

    “All models are wrong, some are useful,” said George E. P. Box in 1976. This is true for automation models too. Automation models are usually nice and clean when we start off. But as the problems we try to solve transform, our models need to grow and adapt. Until at some point they are not useful anymore and we need to replace them with next generation modelling approaches.

    The Configuration Management Model

    Configuration management tools such as Puppet and Chef were originally built to manage application deployment and configuration on static infrastructure. This new approach to Ops optimized manually updating applications on servers. Better network connectivity made it possible for this model to thrive, with the ability to configure applications on servers remotely.

    But within a decade we witnessed the fast rise of immutable infrastructure. Immutable infrastructure is an approach to deploying applications where the infrastructure components are replaced instead of updated. This approach somewhat pulled the rug from under the configuration management model. With each update or change, the application must be re-deployed. This forced adding dynamic infrastructure provisioning to the configuration management model. Combining infrastructure automation and immutable infrastructure concepts into the configuration management model is a difficult task, since this model was never designed to accommodate something like that.

    The Infrastructure-as-Code Model

    Pure Infrastructure-as-Code tools were built to provision infrastructure dynamically. Terraform is an example for an open source tool that does this well. This model is created with infrastructure in mind.

    Whether we look into Terraform, AWS, CloudFormation or ARM templates, we will see the infrastructure is the starting point (defining network connectivity, VM instances and services) and the applications are an implicit addition. They are artifacts that happen to be deployed on and are tightly coupled to the infrastructure. We may look at a component that says “App A” but it actually stands for “specific infrastructure with app A installed on it.”

    This seems natural, because it’s the same way it worked in the good old physical-infrastructure world: We fetch a box, we install something on it. We focus on the infrastructure, because this is our starting point. The application is the artifacts we put on the infrastructure and scripts we run after we provision it. Presumably, the application cannot live without something to be on.

    Infrastructure-as-Code tools evolved the way open tools do–their base model was extended by the community because there was a need to automate applications deployment and not just infrastructure. But it is becoming difficult to extend this model to reflect a world where applications are built to move between clustered servers, and the starting point is no longer the infrastructure, but rather the application’s requirements.

    Mixing Infrastructure and Applications

    Trying to fit infrastructure provisioning and application deployment in a single model that was originally designed for just one of them creates issues. Infrastructure is lower level than applications. Applications reside on the infrastructure. The same app can reside on different infrastructure configurations. This critical relationship is completely flattened if you mix them.

    Moreover, from a business perspective it is important to make applications explicit. It’s our product. Our website. Our mobile app. The applications need to be the center of the attention and discussion. This kind of modelling puts applications in the shade of infrastructure.

    Four Great Reasons to Model Applications as a First-Class Citizen Right Now

    The models we use today are broken, and it is time to evolve. No matter if your applications reside in containers, or on cloud instances, or include native cloud services or a mix of them. Applications should be a first-class citizen, and not some artifact installed as an afterthought on the infrastructure we started from.

    The notion that applications should be abstracted from infrastructure doesn’t eliminate all the challenges of infrastructure provisioning and application deployment, but it creates a foundation for better and more scalable automation.

    1. Achieve Application Re-Use

    Modelling applications as a first-class citizen is the only way to make applications a re-usable element throughout the development and release pipeline.

    If there’s one thing I learned in my automation journey, it is that if automation doesn’t get frequently and consistently reused, you don’t get value for your money.

     2. The Path to Multi-Cloud

    Abstracting application is also the best approach for moving application workloads between cloud providers. If everything starts from infrastructure, we need to start from scratch when we move. If our applications are abstracted and defined separately—this definition stays the same when we move, only the infrastructure changes.

    3. The Path to Breaking Silos

    The vision of Dev, Sec, and Ops all dealing with the same language (code) is wonderful. But bringing everyone to the same code pool is not always easy. Applications and infrastructure are not the same thing, even though we can code both. Mixing them makes them unnecessarily hard to build and troubleshoot. It forces us to deal with fuzzy boundaries when it comes to responsibility for this code. Basing automation on a model that organizes the world in a way the different stakeholders can understand it, can help overcome this barrier.

    4. Connect Infrastructure to Business Needs

    Infrastructure-as-Code is a huge breakthrough, but the bigger story is about making application development and release faster. This doesn’t undermine the importance of infrastructure; infrastructure is the foundation of everything. But if we want to solve business problems, we need to talk the language of the business, and that’s the language of applications. Our automation should be built in a way that reflects this.

    — Maya Ber Lerner

  • Automated Certificate Management No Longer a Luxury

    Automated Certificate Management No Longer a Luxury

    On December 6, 2018, approximately 32 million customers of the UK telecom provider O2 woke up to a frustrating reality: The most widely used mobile network in the country was experiencing a day-long outage of its 4G mobile network.

    For some, not being able to check the weather forecast, traffic report or football scores was a minor inconvenience. For others, the impact was much more severe, as people throughout the country realized they couldn’t collect email, use their connected apps or perform any other task requiring data usage—no matter how critical to their business or personal lives. The world quickly came to realize that O2 subscribers in the UK were not alone: Other mobile providers around the globe, including Softbank in Japan, suffered similar outages in the same time frame.

    What caused this global outage? Was it a software bug? A poorly tested update, shared too soon? Maybe even a cyberattack targeting mobile network infrastructure? In the end, the explanation was much simpler: A digital certificate expiration in a back-end mobile data service from Ericsson caused a cascading systems failure, ultimately resulting in data outage for these mobile services. This issue highlighted the potential impact of certificate errors in our modern digital enterprise and the value of automation in managing such a critical process.

    Human Errors, Absences Lead to Outages

    While the O2 and Softbank service outages had serious consequences in their home countries—the U.S. equivalent would be a provider like Verizon losing data service for an entire day—they are hardly the only ones to experience this issue. Earlier this year, during the shutdown of the U.S. Federal Government, a number of important sites went down or lost functionality because no one was there to manually renew expiring web certificates. Even popular agencies such as NASA and critical services such as those provided by the Department of Justice were not spared, and both agencies and the citizens they serve were forced to watch helplessly as their certificates expired and services went down.

    Although it is of little comfort to the customers who woke up without mobile data or citizens who were unable to use government services, this scenario could easily have been prevented had automation been utilized to manage the certificates in question. When certificates are managed manually, it isn’t always easy to determine the cause of an outage like the one experienced by O2 and Softbank. An expiring certificate may not be the first answer that springs to mind, and may only be noticed after poring over code, looking at network monitoring and checking other potential culprits. Certificates are not always front of mind for IT teams, which underlines the value in simplifying their management.

    The technology sector has made significant strides in this regard, and organizations have tools available to them that can help streamline certificate issuance, management, renewal and revocation. Gone are the days when certificates had to be manually issued one at a time, and organizations kept spreadsheets of certificate expiration dates hoping they remembered to renew them. While we’re not able to say specifically why or how the root-cause Ericsson certificate was allowed to lapse, unexpected certificate expirations can be eliminated through proper use of certificate automation—making such a disaster unlikely to repeat itself if the proper steps are taken.

    Peace of Mind at Scale

    Getting started is easier than you might expect. The rise of automation in managing digital certificates presents organizations with a simple and exciting solution that extends well beyond just outage protection. Perhaps best of all, many organizations operating in a Windows environment may already have access to auto-enrollment and auto-renewal tools using the Microsoft CA, which has been a pioneer in the field of automated certificate services. Chances are, you may already be familiar with using Microsoft CA as an easy way to take care of your internal (private) certificates.

    But what about public certificates? True, Microsoft CA doesn’t handle those, so most organizations will need to find a third-party vendor to manage the SSL certificates for their web servers, load balancers, VPN devices and other networking gear. There are vendors capable of managing all certificate requirements under one roof, whether you operate in Windows, MacOS, Linux or other environments. The rise of standards like the Automation Certificate Management Environment (ACME) have made integrating different environments increasingly simple.

    Designed by the Internet Security Research Group, ACME has become a popular certificate management tool. More than 150 million websites and 130 open-source client tools use ACME. In fact, ACME is supported by a number of tools familiar to those who use DevOps to manage deployments, including Kubernetes, Chef, Ansible, Salt Stack, Terraform, Istio, Docker and others.

    As enterprises look to leverage DevOps with increasing regularity, effective certificate management can help facilitate container, micro-service and application security. Furthermore, orchestration tools such as Kubernetes support certificate management natively, leveraging ACME as the underlying protocol. The private keys may be stored in Kubernetes Secret or Hashicorp Vault so the certificate management system integrates seamlessly.

    Digitally signing your DevOps containers with a private CA helps verify the identity of a given container as it communicates over TLS while also preventing unauthorized applications—and the tools available to ACME users add significant value. Of course, this is just the tip of the iceberg—using automation to manage these certificates means plugging into a vast ecosystem of resources, reducing deployment time and eliminating the possibility of human error. It really is that simple.

    A New Automated Future

    Certificate management is hardly the only area where human error can have an outsized impact, but the O2/Softbank outage clearly illustrates severe effects such errors can have. Service outages, damaged reputations and frustrated consumers lie in the wake of poorly managed certificates, and organizations are increasingly turning to automation to solve the problem. As protocols such as ACME become integrated into an increasing number of commonly used web tools and outside vendors expand their ability to shoulder the certificate management burden, it will only become easier for organizations to incorporate automated elements into their own environments.

    — Abul Salek

  • Focus on High-Level Policy Requirements to Accelerate Network Processes for DevOps

    Focus on High-Level Policy Requirements to Accelerate Network Processes for DevOps

    Network operations traditionally has been the missing piece in DevOps processes. It’s not difficult to see why. Network management has lagged behind server and workload automation. Updating network policies and configurations typically requires a great deal of analysis, testing and time, undermining the goal of DevOps agility. But once we shift how network devices are administered and how changes are validated, there are emerging ways to incorporate network updates and policies into DevNetOps processes through automation.

    Shift the Focus to Policies, Not Configurations

    DevOps has taken off, thanks in part to the ability of virtual networking and software defined networks (SDN) to automate the placement of workloads, establish connectivity and deliver Layer 4 to 7 services in a few minutes. But virtually all network policy updates, particularly those addressed in the underlay, were constrained by having to reconfigure individual network devices through traditional management platforms or command line interfaces (CLI). New application deployments may require new network paths, access to cloud resources, punching holes in firewalls, etc. There was no way to automate these policy-related tasks through existing network management platforms, and DevOps processes were limited to simple changes that could be made in the overlay network.

    Figure 1: The CLI management model and box-by-box management, in general, do not facilitate DevOps processes, which require higher level policy specifications and requirements. DevOps requires the automation of such policy analysis and verification.

    What’s wrong with updating individual network devices through CLI? Network administration is hampered by the inherent nature of IP networks individual devices never have a holistic end-to-end view of network policies and behavior. They are usually configured to know what to do with traffic locally, when to drop it and when to forward it to which nearest neighbor. This is not how policy requirements are formed (see Figure 1).

    If a new DevOps deployment needs to ensure a rack in Data Center 1 can reach a rack in Data Center 2 through a specific secure gateway, then to a cloud-hosted database and return traffic appropriately, then we need a much broader, path-based view than any individual device or CLI can give us. If we are going to automate any of this analysis or verification, we are going to need a solution that maps our intended policy requirements to network implementations across many devices.

    Intent-Based Networking Aligns With Policies and Intent

    This is where intent-based networking (IBN) can help. IBN can help bridge our application policy requirements with the network design and configuration. It can allow us to verify if a particular policy requirement is supported in the network currently or help with a path-oriented search to quickly identify which devices need to be updated to deliver the particular policy. Changes, such as updating a firewall rule, ultimately may still be made to a single device through a CLI, but we have accelerated the analysis if the policy is currently supported, what changes need to be made and how such a change may adversely affect other existing policies and requirements.

    For example, it may be an enormous benefit to application development teams prior to deploying a new workload, to be able to determine if connectivity from our Rack 1 servers to a remote database is available for new traffic requirements. Typically, this might involve a request to the network team, which would have to analyze the policy requirements or arrange for a test scenario. A trouble ticket request such as this would take more than just a few minutes, even if the network team could jump right on it.

    Application Team Self-Service

    Imagine instead the application team could self-service their request by querying an IBN system that could immediately verify the implementation of the policy. Perhaps the application team could use a simple internal messaging platform such as Slack to specify their policy requirement and get an immediate answer without further analysis by the network team. They wouldn’t even need to learn the GUI or capabilities of the underlying IBN platform with a Slack messaging front-end.

    An IBN solution gives teams the power to avoid thinking in terms of individual device rules and opens the door to end-to-end automated policy analysis for the first time. Application teams could never be expected to understand firewall configurations or be able to self-service their queries about those capabilities, but they can think in terms of high-level application policy requirements and end-to-end path behavior, which IBN platforms can deliver (see Figure 2).

    Figure 2: A sample policy query is constructed in the top bar, as the IBN platform shows a number of available paths between data centers that map to the policy requirements.

    Automating Network Verification

    To further accelerate key network policy changes required for DevOps processes, imagine updates are required to individual devices in the underlay network. Not only can those changes be identified nearly immediately now through IBN, but also the verification that the changes were made correctly and didn’t adversely affect any other applications or policy requirements can be completely automated. These IT tasks of analysis and verification were usually the most manual and time-intensive in the network operations workflow. But now that much of the workflow can be automated, DevOps can benefit greatly.

    The verification process would consist of a long list of existing policy requirements that were already in place and implemented. After a proposed change to network configurations, all of those policies could be analyzed quickly to determine if the new update adversely affected any prior requirements, preventing rollbacks or potential security or compliance breaches.

    The question naturally arises, What is really enabling this shift in network operations from a box-by-box focus to an end-to-end, path-oriented policy focus? IBN platforms have generally replicated much of the analytical intelligence of network engineers to determine overall behavior from analyzing individual device configurations and state information. Much of this intelligence is based on mathematical models of the running network in software and much less so now on analyzing live traffic under limited scenarios. This analysis of the mathematical model in IBN platforms now can provide definitive verification of policy requirements for the first time, and even identify configuration errors long before they can cause loss of service or an outage.

    The key to accelerating network analysis and updates in support of DevOps processes is to shift focus up from individual box-by-box device management and CLI interfaces to focus on end-to-end network behaviors that align with application policy requirements. Application team self-service for many policy-related network requests and automation of network verification tasks are just a few of the benefits for DevOps teams that IBN can deliver today and into the future.

    — Chiara Regale

  • How IoT Security Risks Derailing Robotics

    How IoT Security Risks Derailing Robotics

    Driven by advances in technologies such as artificial intelligence and deep learning, the mobile robots market is projected to grow to $54.1 billion by 2023 from $18.7 billion last year, according to Markets and Markets. But for robotics to progress, security for the internet of things (IoT) needs to be addressed fast, before the reputation of the entire industry suffers a permanent setback.

    Every industry segment has a journey to maturity that involves ramping up how seriously it takes security. For robotics, that time has come. Failing to start robotics projects on the right software foundations will see confidence continue to drop, impeding the rate at which new solutions are created.

    The future of robotics rests firmly on the shoulders of the IoT. Robots act as one part of intelligent ecosystems—they depend on IoT to link various sensors and smart meters, and pass data to and from third parties.

    The self-driving car, for example, is a robot orchestrated by various smaller devices and smart sensors. In fact, robots are being created to tackle every conceivable problem. Take the Google-funded RangerBot, an underwater machine designed to track down a species of starfish responsible for coral reef destruction, or Small Robot Company, a startup tackling farming deficiencies with bots that autonomously feed, seed and weed arable crops.

    However, while IoT is an established concept and connected devices are now mainstream, its full potential has not been realized in part because of security concerns. Ninety percent of consumers lack confidence in connected devices, according to a recent survey. These concerns are more than valid, as nearly half of companies are unable to detect when a breach occurs, and only 15% of budgets are earmarked for IoT security.

    With IoT security a lingering weak spot, one major attack within robotics, could have a domino effect on the entire industry. Add to this the verticals that robots are beginning to infiltrate—health care and agriculture, for example—and the threat becomes immediate and very real.

    Rising levels of sophistication within robotics go hand in hand with more targeted and damaging attacks. For example, telesurgery uses robotics to help surgeons perform procedures remotely. A malware bug in this scenario could mean the downing of tools, threatening the patient’s life.

    Researchers at Brown University proved how easy it is to hack robots. The industry simply will not be sustainable without the backing of a secure, connected IoT network.

    Robot manufacturers, therefore, must build with a security-by-design mindset. This begins by selecting a robust operating system from the outset—secure now, but also ready for future market demands.

    Hackers are constantly evolving their activities and businesses must be flexible in their approach to security, shedding the old hardware-centric view of IoT security.

    Software no longer can end when a device is shipped. It must align to the lifespan of a robot and be able to update whenever there is a potential flaw. The world of mobile took many years to get to grips with this. Robotics and IoT developers should learn from their mistakes.

    One way developers can safely build and secure software is through snaps, containerized software packages on an open platform for building and publishing applications to an audience of millions.

    If a security vulnerability is discovered in the libraries used by an application, the app publisher is notified so the app can be rebuilt quickly with the supplied fix and pushed out. This allowsr developers to stay focused on innovation while ensuring the longevity of the robotics hardware.

    It remains unclear where the onus lies for IoT security, with nobody holding anyone else to account. Market constraints often prevent device makers from putting more budget than what is necessary into design security, when there is so much pressure to innovate ahead of competitors.

    These issues need to be solved. Robotics has too much potential to let security concerns stunt their growth.

    — Tom Canning

  • Digital Transformations Fall Short, Survey Claims

    Digital Transformations Fall Short, Survey Claims

    What is the nature of digital transformation? Is it a permanent shift in the digitization of business processes, or a race to a known destination? Should organizational investments in data analytics, continuous software development, business processes, culture, machine learning and shifting enterprise technology from a perspective of ownership and control to consumption be judged from the eye of the consumer?

    The answer seems straightforward. Eventually, the market is the ultimate arbiter of digital transformation success. However, many organizations today are busily investing in technologies they hope will serve them well in the years ahead, and some of the largest investments are not immediately visible to consumers.

    According to the Kony Digital Experience 2019 Index Survey report, businesses are “still missing the mark” with consumers despite nearly $5 trillion in digital investment. The report didn’t distinguish how the $5 trillion was being spent and in what areas of the business the investments were made.

    “As companies race toward digital transformation, their leaders might want to hit the pause button and reassess their efforts. The significant investments by companies around the world to transform their business to become more digital has had very little impact on consumer experience,” according to the report.

    Perhaps—or, perhaps, many organizations are laying their groundwork and it’s way too early to make such a call.

    According to the survey, customers (65%) are more satisfied if their digital experiences feel effortless (who wouldn’t?) and 63% of customers said they would spend more money if their digital experiences feel effortless. Of course, history is full of surveys detailing consumers stating how they’d act but consequently end up acting entirely differently; people are notorious for answering surveys how they think they should answer or how they wish they would act rather than how they do act. Famous examples include surveys on privacy, security and personal finance.

    The findings of this survey are based on 1,600 respondents across the U.S., Europe and Asia. According to Kony, 800 were participants or leaders of digital transformation initiatives in organizations with 500 or more employees.

    The study focused on business investments and customer experiences within the banking, retail, utilities and healthcare industries.

    Interestingly, respondents said organizations in banking (54%), retail (59%) and utilities (51%) are keeping pace with their expectations but are not delivering differentiated digital experiences. The big laggard was health care, with only 48% keeping pace and 20% being behind respondents’ expectations.

    The study concludes businesses are not listening to—or understanding—the evolving needs of their customers because only 28% of enterprise digital transformation initiatives are started specifically with customer needs as the priority.

    “Improvements in costs and efficiencies are always welcomed and clearly important to project funding, but the real returns and real impact of digital starts and stops with its impact on the customer experience,” said Thomas E. Hogan, chairman and CEO of Kony Inc.

    That’s an incomplete way of looking at what is happening when it comes to digital transformation and the scope of technological change underway. That figure and comment are based on the survey findings that 68% of digital transformations were business process-centered, 4% employee experience-centered and 28% customer experience-centered.

    My take: In most cases, business leadership knows what they need to do and where they need to place their primary focus. And it’s a tough call to broadly state businesses are missing the mark without looking at how specific businesses are choosing to invest, as well as their stated objectives. Such information was not available in the survey.

    In many—if not most—cases, businesses are focusing on what they need to do, such as eliminating technical debt, automating business processes with robotic processes, streamlining their development pipelines and more. Of course, it’s essential to provide quality experiences to customers, as the survey found 47% of consumers will consider switching providers if their current provider doesn’t deliver the digital experience they demand and expect.

    That said, it’s not always true that digital transformation begins and ends with the customer. Large enterprises have decades worth of technology investments they must manage, and successful digital transformation isn’t a set finish line that enterprises are rushing toward. Rather, it’s a never-ending continuum, and those enterprises that are investing in the removal of technical debt, modernizing their software delivery methods, machine learning and streamlining their businesses to be more cost-effective and agile are building platforms that will sustain their businesses and provide exceptional digital experiences over the long haul.

    — George V. Hulme

  • How Low-Code and No-Code Solutions Compare to RAD

    How Low-Code and No-Code Solutions Compare to RAD

    Low-code and no-code solutions help line-of-business workers to create applications more quickly and advance business needs. But how do low-code solutions compare to the rapid application development (RAD) tools of yesterday for non-developers? Let’s take a look at the drawbacks and advantages of the low-code solutions of today, who should use these solutions and which application types are best-suited for low-code/no-code.

    RAD vs. Low-Code/No-Code

    First off, let’s discuss some of the key differences between RAD and low-code/no-code solutions. RAD solutions are development tools that combine an integrated development environment (IDE) with some code generation features, primarily on the UI side.

    No-code/low-code, on the other hand, refers to platforms on which codeless design time produces fully deployed applications, whether in the cloud or on-premises. This includes the entire application technology stack—back end, middle tier and UI. While it might not be accurate to say all low-code solutions are RAD solutions, it would be accurate to say low-code is an offshoot of RAD, though a far cry from the RAD solutions of the early ’90s.

    Low-Code and No-Code Advantages 

    Modern low-code and no-code platforms are advantageous to non-professional developers because of their shorter learning curves. These solutions cover the entire application stack and development, testing and deployment process. There is also no need to install multiple components to create a fully functional development environment, as most of the new tools run in a browser and deploy in the cloud.

    Low-Code and No-Code Drawbacks 

    The drawbacks of low-code/no-code platforms are similar to those experienced with RAD. You still need to deal with the code, since in many cases the developer has no control or knowledge of what files were generated or modified as a result of visual tool-related activities. This affects source control approaches and integrations of the code with third-party components. Furthermore, the quality of generated code can be questionable and proprietary in some implementations. This can lead to issues with code integrity across implementations if care is not taken.

    One of the key factors of measuring the quality of the generated code is it should use the most popular and widely available (open source) frameworks instead of proprietary frameworks, so further maintenance of the code is straightforward and does not require an additional learning curve. The quality and complexity of the generated code also should be measured using traditional tools.

    When to Use Low-Code/No-Code 

    Which applications work well with low-code/no-code development? Because low-code and no-code allow developers to concentrate on the business logic of building blocks, this strategy is well-suited for business-type applications. Low-code building blocks and components can be created by more technical people also by injecting some code into standard visual components, ending up with no-code required building blocks for businesspeople to construct applications. This approach also fits well into the “bimodal IT” approach popularized by Gartner.

    Low-code/no-code and RAD were both built with the same end goal in mind: to speed development and deliver applications more quickly and more consistently. However, low-code solutions offer a more visual way of building apps more well-suited for less experienced developers. It also can empower team members who otherwise would not be able to do so to create applications more easily. Modern low-code solutions also give the developer a great deal of flexibility because typically you can incorporate both the low-code building blocks with custom code, meaning the application can be customized.

    Whether you’re new to low-code or no-code or just getting started, this solution is a great choice to help accelerate part of (or even your entire) development pipeline. If you’ve tried RAD in the past, give no-code/low-code a try and see if it’s right for you.

    — Dmitry Binunsky

  • Consider the Role of Programmers as Storytellers

    Consider the Role of Programmers as Storytellers

    Every time I speak with the programmers of our team in casual conversation, I ask what they’re working on. Every time, I get the same kind of answer, “I’m building a dashboard,” or “I’m optimizing a database,” or “I’m testing the user interaction.”

    In other words, I get the same answer as the proverbial masons, “I’m laying bricks,” or “I’m building a wall.” But not, “I’m building a cathedral.”

    At an abstract level, programmers understand the value of the big picture. But at a practical level, they focus on the immediate next steps. Since time is always crunched, programmers skip absorbing the big picture.

    “This is a mistake,” I told them. “Your work improves if you know why you’re doing what you’re doing.”

    “How?” the curious ones asked. That’s when I told them the story of Andre.

    Andre told me he was creating a dashboard. I decided to ask him the five whys.

    1. “Why are you building this dashboard?” I asked. “Because my team leader told me to,” said Andre.
    2. “Why does he need it?” I then asked. “Because the client Rudolph told him to build it,” he answered.
    3. “Why does the client need it?” I continued to ask. “Because his boss told him … I guess?” he replied.
    4. “Why does his boss need it?” I asked him. “I don’t know,” he said.

    I knew I couldn’t get further. So, I asked to see the dashboard. It showed 14 metrics and their performance across time. I had no idea what I was supposed to infer from the numbers.

    I spoke to Rudolph, the client, and asked why he needed the dashboard. His answer was similar, “Because Victor, my boss, wants to know how our operations are doing.”

    “So, do you need all 14 numbers? As a table?” I asked him. “Yes,” he said. “I need to know how each number is performing.”

    I tried a different tack. “Suppose you’re on an elevator with Victor, and he says, ‘Hi Rudolph, how’s it going?’ How will you answer? Are you going to recite all 14 numbers to him?”

    Rudolph thought for a while and said, “No. I’ll probably just tell him about what’s improved and what’s worsened. Then I’ll tell him what I’m going to focus on improving. That’s all that matters to him.”

    That left Andre and me wiser. Our aim was not to show 14 metrics. It was to help Rudolph and Victor figure out what’s improved and worsened.

    This helped Andre change three decisions.

    Change the Development Priority

    Not all metrics were equally important. Some were consistently stable. Some fluctuated a lot. He wrote the queries for the fluctuating metrics first. So, when the deadline hit and he wasn’t fully ready, he still had the most important metrics in place.

    Change the Design

    He added simple traffic-light colors to the metrics that grew the most and fell the most. It made it much easier for Rudolph to figure out what’s improved and what’s worsened. Rudolph never commented on it. But we knew without it, his response would have been, “There’s something wrong with this, but I don’t know what.”

    Change What to Optimize

    The queries run slowly. Rather than optimize all queries, Andre reordered the queries to render the fluctuating metrics first and optimized those. Those results appeared first, markedly improving how fast the dashboard appeared to load.

    Conclusion

    There’s a reason modern agile processes refer to user stories to capture requirements. But we lose the spirit of the story when we write, “As a user, I want to see the performance of 14 metrics.”

    The next time you write a requirement, don’t hesitate to write the full user story for the programmers. “When my boss is in the elevator and asks for a quick summary, I want to tell him what’s improved and what’s worsened, in less than 10 seconds.”

    Stories are memorable. They are easier to understand and communicate. They help explain why we’re doing what we’re doing. They also help prioritize development, improve the design and optimize better.

    Always ask for requirements as stories. Always narrate requirements as stories.

    — S. Anand

  • 3 Reasons Why Ephemeral Access is Best for DevOps

    3 Reasons Why Ephemeral Access is Best for DevOps

    Recently, we worked with a customer, MOST Digital, whose developers were struggling with a common workflow challenge we hear from many companies.

    The company is in the software robotics automation space—it essentially makes little robots that automate all sorts of business processes for a company, such as HR report filing or routine emails. MOST Digital developers need access to customer environments to fetch data, often jumping in and out of on-premises and cloud platforms to do so.

    The problem was developers had to use client-specific jump hosts and VPNs to transition between IT resources. The process was slow, complicated and difficult to manage, which made life more difficult for MOST Digital’s team. Projects were delayed as they had to wait to receive help from each client’s IT organization.

    “This wasn’t what MOST Digital wanted for their team,” said Sami Säisä, director and head of strategic development at MOST Digital. “We want to provide them the best environments and best tools that there are available.”

    It’s a common refrain we hear from many customers, and it makes sense. The easiest way to frustrate a developer is to throw obstacles into their workflow. Unfortunately, most common secure access solutions create obstacles, and it’s not just jump hosts or VPNs. Even privileged access management (PAM) solutions, which are supposed to simplify and centralize IT credential management, are traditionally too bulky, complicated or non-intuitive for modern workflows. That encourages developers to bypass PAM altogether, which creates a major security risk.

    So, what’s the best way to overcome the complexity brought on by credential management? Well, why not just get rid of permanent credentials?

    Ephemeral certificates are a modern form of secure access that are temporary, time-based and automatically expire. Here’s why they’re a better solution for companies that want to keep modern developers happy.

    Ephemeral Certificates Offer ‘Just in Time’ Access

    Developers are building and coding in a world that emphasizes speed, agility and elasticity. They’re taking advantage of state-of-the-art tools meant to make it faster and easier to do work. They’re taking advantage of modern, hybrid IT environments that combine multiple cloud infrastructures in an attempt to find the most effective mix of resources for development and deployment.

    The last thing they want are processes that slow down workflow. Unfortunately, secure access today often means doing just that: slowing down and stopping to manually input credentials across environments. Developers might also share credentials among each other to try and speed up work, but that creates yet another security risk.

    Traditional PAM solutions don’t make the process any easier. Those tools create a central vault to manage an organization’s secure credentials. Privileged tech users, such as developers, have to use them to access and authenticate their credentials. PAM grants access per user and per host, so a new, permanent credential needs to be created every time a new developer, contractor or contributor needs access to a new IT resource.

    However, most PAM tools were not built with the workflow of the modern developer in mind, so they slow things down while also encouraging loopholes and workarounds that compromise organizational security.

    Ephemeral certificates overcome all of this by eliminating manual credential inputs. Gartner refers to these as just-in-time access, because access credentials are created on-demand automatically and require no installation, configuration or updating. In other words, they free developers to focus exclusively on the work they do best.

    Ephemeral Certificates Eliminate Bad Habits

    Rather than deal with all of the typical secure access challenges, some developers will often bypass PAM solutions altogether, instead choosing to spin up their own SSH keys to access the IT resources they need. Those keys exist outside of the PAM solution—they are untracked and unmanaged.

    Not only is it a policy violation to have developers find workarounds for IT-approved security practices (not to mention a huge waste of the investment in a PAM solution), but it also creates a security risk.

    The best way to encourage policy adherence is to make your policy easy to follow. Developers won’t bypass your security solution if it’s easy to use, and ephemeral certificates are inherently simple.

    There Are No Credentials to Misplace–Or Have Stolen

    If every developer is creating their own SSH keys to access IT assets and no one’s keeping track of them all, what happens if one is lost or when that developer leaves the company? Suddenly, there are keys laying around that could be scooped up and used as an all-access pass to systems in your environment.

    How do you monitor and audit this type of shadow IT access? How do you trace non-policy compliant access from development to production? How do you prevent developer access to sensitive data?

    Ephemeral certificates are inherently more secure because they are temporary, only existing for the period during which access is required, and automatically expire as soon as you are done using them.

    As a result, there are no credentials to lose, misplace or steal, leaving fewer old credentials lying around for someone to take advantage of down the road. On top of that, ephemeral certificates don’t leave user-specific access credentials stored on target servers, so if someone does get access to your target server, they won’t be able to find any credentials that could be used to hop to other systems.

    Ephemeral Access Is a Step Closer to DevSecOps

    From security to IT management, there are lots of reasons why ephemeral certificates are a better solution for businesses. But the single most impactful use case is making your team’s life easier.

    Want to frustrate a developer? Throw some obstacles into their workflow. But if you want to keep your developers busy on value-driving activities, get rid of outdated and unmanageable workflows. They’ll thank you for it later.

    — Markku Rossi

  • How Serverless Is Impacting the IT Landscape

    How Serverless Is Impacting the IT Landscape

    Although most users will never realize it, with every digital data entry and exchange servers are consuming substantial quantities of energy to file, store and sustain that data’s availability.

    While the average consumer or office worker doesn’t consider the economic or environmental impact they have, IT and C-Suite teams are awakening to the problem and the awareness among energy concerns, legislators and thought leaders is growing. From the expanding troves of transactional data for AI to each video streamed on a smartphone or to a social media platform, hyperconnected companies are hungry to collect, understand, feed and leverage data on our digital habits. In today’s infrastructure models, data centers continuously burn through processing power to be ever-ready to those workloads—even when demand falls during regular off-peak periods.

    That’s one of the two real pushes behind the shift from legacy to new serverless infrastructures: waste, both environmental and economic.

    The world is waking up to the realization that the digital economy is consuming disproportionate levels of energy, putting new pressures on their organizations, their region’s energy infrastructures and, ultimately, on the planet.

    A recent report from Climate Change News predicts billions of internet-connected devices could produce 3.5% of global emissions within 10 years and the communications industry could use 20% of all the world’s electricity by 2025. In fact, data from statistics portal Statista notes the energy consumption of Facebook usage alone amounted to about 2.46TW hours in 2017, compared to 532GW hours in 2011.

    In the U.S. alone, data centers consume an astounding 90 billion kWh of electricity per year, the approximate annual output of 34 (500MW) coal-burning power plants. The data center consumption costs are baked in—organizations pay for always-on computing power to meet peak need regardless of how demand may fluctuate.

    The Promise and Potential of Serverless

    Cutting Energy Consumption: Serverless compute technology such as Amazon’s AWS Lambda or Microsoft’s Azure Functions are native cloud architectures designed to decrease consumption and increase agility and innovation.

    It provides a more efficient function-as-a-service (FaaS) consumption model that enables organizations to pay for what they use, rather than constant peak demand charges.

    Some of the economic impacts of serverless are obvious: Organizations that host their own servers have reconciled themselves to paying for those servers running at full power while sitting idle for much of the time. It’s like keeping your car constantly running, regardless of whether you’re going anywhere.

    In contrast, serverless not only promises far greater energy efficiency from the macro-infrastructure perspective, it also is event-driven. Organizations pay by the computing power consumed, so their costs reflect their actual server usage rather than paying for always-on capacity.

    The Shift Is On, From Managing Infrastructures to Solving Problems

    Reduced energy consumption and cost efficiencies are important for organizations and the planet. Two other major promises serverless offers are the ability to let organizations focus on creating applications and services without chaining them to infrastructure and innovation opportunities.

    Organizations shift the focus of their IT resources away from infrastructure maintenance—the provisioning, patching, operating system maintenance, managing runtimes and capacity planning overhead—to solving business problems. This means the focus of the organization’s IT resources can shift from managing infrastructure maintenance burdens to doing what IT was always meant to do: solve actual business problems.

    But there’s another aspect to serverless that’s even more exciting.

    Unlocking ‘Vendor Lock’ and Unleashing Innovation

    Every great technology breakthrough inevitably tears through old barriers and accelerates innovation. Serverless is no different.

    Furnace is a good example. It’s a new open source, serverless, streaming data processing platform for building big data solutions that are cloud platform and language-agnostic.

    It supports the use of applications that run natively in AWS Lambda, Microsoft Azure and Google Cloud, passporting data between platforms. Using coding languages including JavaScript, Node, Python and Golang, a growing community of developers are creating constructs to connect cloud-based applications.

    Some of the most urgently needed application construct types we’re likely to see in the near term will be for extracting and anonymizing old proprietary data for GDPR compliance, and for honeypot data collection and manipulation, with Elasticsearch and Redshift. Other application foundational on-ramps are in development.

    According to Danny Waite, CTO for the Furnace Ignite organization, the Serverless Furnace source platform was architected to allow deployment and data traversal into and across various cloud, on-premises and hybrid environments, putting the underlying efficiencies of serverless to work on practical applications.

    The application development platform is optimized to ingest massive volumes of data from different sources and in various formats. The Furnace open source community is soliciting feedback and community developers are working on various projects, with plans for constructs to harness and tap into the massive stores of now-untouched IoT data, among other sources.

    Greener, Cleaner, Streamlined Computing

    Serverless is a driver for ecologically greener, operationally cleaner and innovation-driving new computing. Its reduced data-center energy consumption, pay-per-use event-driven model, openness to innovation and seemingly unique ability to help align historical data with new regulatory requirements are all arguments for a shift in thinking and embrace of serverless. The improved economics are another compelling reason, though likely not a primary one for data-driven organizations.

    Serverless communities such as Furnace Ignite are emerging with tools and techniques for adoption. The Furnace application development platform has been architected in a way that allows it to be deployed into various infrastructures, such as cloud, on-premises or within hybrid environments, with the ability to ingest huge volumes of data from different sources, in various formats, so developers can take that data and make it useable. The whole process can be done with speed and agility and removes all the nuances normally associated with working with streaming data.

    Serverless platforms such as Furnace will continue to be developed to drive DevOps and meet the needs of the opensource community.

    — John Blamire

  • Product IT Operating Model: The Next-Gen Model for a Digital World

    Product IT Operating Model: The Next-Gen Model for a Digital World

    Digitization presents many new opportunities for businesses to create value. At the same time, it forces IT to rethink the way it operates. Modern CIOs need an operating model that understands the blurring lines between IT and business and is designed for agility and speed. The product-centric IT operating model is rapidly emerging as the answer.

    What does the model entail? In the product IT operating model, product lines are funded based on their strategic value to the organization, from the top-down, and are supported by dedicated management and delivery resources. The entire product team is measured on a common set of goals, which include customer experience, time-to-market, efficiency improvements, quality of software and availability and reliability of production environments.

    5 Dimensions of Product IT Operating Model

    Adopting a product IT operating model requires organizations to take an integrated approach toward product-based development and embark on a journey of continual improvements. While scaling agile DevOps that aligns business outcomes with engineering effort, enterprises must focus on these five key dimensions:

    1. Organizational Change Management (OCM): Successfully transitioning from the traditional IT operating model to a product-based development approach requires organizationwide change management. An experienced IT service provider, can prove to be a key ally in ensuring a smooth transition.

    2. Culture: Culture is an intrinsic characteristic of any organization, and instituting small but effective cultural changes coupled with OCM is the right approach to transition, rather than a “big bang” change. That’s also what some of the well-known enterprises across industries are doing.

    a. Teams and Collaboration: The alignment of large teams across multiple organizational groups delivers to a common plan on the pace of change and helps to continuously embed innovation and experimentation for improved services.

    3. Structure: Product-focused and highly talented teams across design, architecture, DevOps and operations are key to enhancing business capability. By measuring the entire team on same set of goals, it is easy to enhance customer experience, efficiency and quality of software while creating a stable production environment.

    Structure also means aligning traditional application portfolios to specific business outcomes and bringing together all the capabilities and resources required for an organization to deliver on its business outcomes.

    4. Technology: If business models, organizational structures, people and ways of working are the gears that run the enterprise IT engine, technology is the grease that enables this engine to run smoothly, without friction. Two key aspects of technology include:

    a. Application Programming Interfaces (API): API-based architecture provides an extensible framework of building blocks, which in turn can be used to build powerful applications or software products. Easy maintenance is a hallmark of API-based architecture, as it can be quickly migrated further to any other target architecture.

    b. Cloud, Microservices and Containers: Modern organizations need on-demand scalability. Cloud and microservices enable just that without disturbing ongoing business operations. However, it is important to first understand an organization’s product vision and road map, business priorities, competition, pace of market transition in their area of business and industry trends before choosing cloud or container-based infrastructure.

    5. Process and Automation:

    a. Agile Delivery Model: This is a critical prerequisite to building a minimal viable product (MVP), ensuring rapid delivery of critical enhancements or delivering a suite of product features in appropriate increments. Industry-standard agile practices such as LeSS and SAFe should be used, as they allow complete flexibility to tweak the model on the fly.

    b. DevOps and DevSecOps: A DevOps culture is fundamental to adopting a product IT operating model. Continuous integration and delivery (CI/CD) require DevOps to be fully interwoven into the software development life cycle (SDLC), along with the right tools and governance mechanisms. This ensures high-quality products are delivered within short deployment lead times, along with the ability to fix production issues with low mean time to restore (MTTR) and ensure minimal to no change failure rate. DevOps also enables new-age practices such as automated testing, self-service access to infrastructure and automated performance management.

    DevSecOps goes hand-in-hand with DevOps. It ensures security aspects are built into the products across the delivery pipeline, so the products are not only fault tolerant but also fool-proof, to a large extent. An experienced DevOps team builds and integrates security tools, solutions and processes to safeguard the organization.

    c. Test Automation and Test-Driven Development (TDD): By integrating test automation into the development process, the product IT operating model allows organizations to create high-quality and quickly deployable products. Additionally, TDD enables governance to be integrated into the delivery pipeline by developing quality code in line with test cases written to describe user requirements more precisely. Tests are fully automated to ensure quality of code.

    d. Service Health: With KPIs focused on the financial health of engagement, it’s easy to set a budget based on business capabilities and product levels to meet business goals effectively. The KPI framework encompasses key KPIs such as business, financial, learning and innovation and employee engagement outcomes, while staying flexible enough for different contracting models.

    Delivering Value in a Changing Business Environment

    Digitization mandates that IT deliver on three important aspects: Improve time to market, optimize costs and increase quality.  Adopting a product IT operating model helps IT deliver on the mandate by enabling a fail-fast way to deploy software quickly and cost-effectively, without sacrificing quality. However, given the extent of change involved in the shift, it is not something that can be achieved overnight. It must be underpinned by a journey of cultural change and continuous learning, using tools such as design thinking-driven, persona-based change journeys, alignment workshops and targeted campaigns and communication. Partnering with an expert system integrator can help organizations jump-start the process and ensure on-track transition with minimal disruption to business.

    — Gagan Jain