devopsy.kinsta.cloud

Category: DevOps Practice

  • 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

  • Why Did DevOps Become So Popular? 3 Theories

    Why Did DevOps Become So Popular? 3 Theories

    DevOps has now been a thing for a solid decade. As we look back at the history of DevOps, it’s worth asking: Where did DevOps come from, and why did it take off when it did?

    In honor of the 10-year anniversary of DevOps, I’d like to explore these questions.

    A Brief History of DevOps

    The very basic history of DevOps goes like this: First, there was agile, an idea exemplified in the Agile Manifesto that gained prominence among software developers in the early 2000s.

    Then, in 2008, Patrick Debois, a developer from Belgium, conceived of DevOps as a way to improve upon the agile concept by encouraging developers to work more closely with ITOps teams. His ideas began spreading in 2009. By the early 2010s, they had gained a sizable following and the rest is history.

    That, again, is a really basic history of DevOps. For more detail, I recommend this DevOps history post by Steve Mezak.

    Why DevOps? Why Now?

    The narrative of how DevOps originated is one thing. Explaining why DevOps became so popular in a relatively short span of time is another.

    As I see it, there are three possible theories to explain the rise of DevOps over the past decade. The first is to argue that Debois simply happened to have some very good ideas, and he promoted them well. You could think of this as the great man theory of DevOps’ origins. This seems to me, however, to be an unlikely explanation. It’s very rare for highly influential ideas to be born from just a single mind, or to spread through the singular efforts of one person.

    The second possible explanation for why DevOps became popular is it is simply an evolved form of agile. This is like arguing that World War II was simply a continuation of sorts of World War I, and therefore the origins of World War II are ultimately the same as those of World War I. From this viewpoint, the history of DevOps is really the history of agile, and so DevOps itself doesn’t have a unique history at all. I’d find this argument compelling if I believed DevOps is really just agile by another name, but I don’t. DevOps is broader, and has a much stronger implementational and practical element.

    The third theory—and the one I find most persuasive—is DevOps was born out of a particular moment in the history of computing and IT. That moment, which started in the mid-2000s, was marked by several key features that helped give rise to DevOps, including:

    • The widespread adoption, starting circa 2007, of cloud computing.
    • The success of the open source software movement around 2010 in making open source the go-to licensing strategy for many popular software projects and in making collaboration around code easier.
    • The rise beginning around 2010 of microservices and containers, which made applications much more complex to design, deploy and manage.
    • The explosive popularity of mobile computing starting with the launch of the iPhone in 2007. The mobile revolution meant organizations increasingly had to deliver software for multiple target environments (PCs, Android phones and iOS, for example) at the same time, necessitating branched delivery pipelines.
    • The demand for ever-increasing speed in software delivery as a way to gain an edge in software markets which, by the late 2000s, had grown more competitive than ever.

    When you put these changes together, you end up with a need to manage much more complex, fast-moving software delivery pipelines. Powered by cloud infrastructure and microservices architectures, the software market starting around 2010 required more responsive, better coordinated management by IT teams. DevOps provided an answer by increasing efficiency, decreasing response times and making software delivery faster.

    I don’t think DevOps would have taken off if the idea had emerged in the 1990s, when there was much less demand for fast software delivery, most applications ran locally and codebases were relatively simple.

    Nor am I sure DevOps would prove as popular if it were first introduced today. At present, we have a litany of management tools (such as Ansible and Kubernetes, to name a couple of examples) that didn’t exist 10 years ago. Those tools make it easier to handle all of the complexity of modern software environments even if you don’t have a management strategy rooted in DevOps culture.

    To put it simply, DevOps resulted from the combination of several specific developments in the world of IT between the mid- and late-2000s. Debois may certainly deserve credit for helping to spread the idea, but it would not have spread so quickly if it had not emerged at that particular time.

    — Chris Tozzi

  • 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

  • DevOps at the Speed of Business: 5 Tips for Success

    DevOps at the Speed of Business: 5 Tips for Success

    It’s an exciting time to be an engineer. With companies today moving faster than ever, engineering teams are developing and deploying new code daily, continuously improving and advancing the business. But while the pace of modern development creates new opportunities for engineering teams, it introduces new challenges as well—in particular, making sure new code releases don’t bring the system crashing down. With more code comes more opportunity for error.

    When organizations scale fast, the challenges compound. As the engineering team grows to keep pace with expanding business, it becomes more difficult to keep track of the new code being developed. This lack of visibility can frustrate even the best teams. Without a clear view into what changes are being made, it becomes more difficult to fix them when something goes wrong.

    What do you do? Here are five key DevOps practices critical for organizations scaling fast:

    Put a Premium on Collaboration and Communication

    DevOps teams, no matter their size, need to be able to share information easily and quickly. When a problem occurs, forensics and root cause analysis must be performed as fast as possible, and engineers need to be able to annotate events that occur within the product deployment stream. Most companies already have the tools to do this, but they often fail to communicate what they find. Opening lines of communication between disparate, often geographically dispersed teams enables everyone to expand beyond their own knowledge base and capabilities to help one another. When everyone can share their knowledge, it raises the collective talent of the entire engineering community, creating a more collaborative learning environment and a culture of sharing.

    Democratize the Tools

    Tools that are accessible only to a small group of power users always fail. There’s not a person in the world who wants to put hours into teaching themselves a new tool if it isn’t approachable and interesting. That’s trouble, because the fewer people that understand how to use a given tool, the more difficult it is to use it to fix a problem. For example, if the ability to query log files is limited to the three engineers who are certified on a tool, the size of your team won’t matter; you can have 50,000 of the best engineers, but effectively, it’s a team of three. This bottleneck can have serious business consequences. Imagine you’re an online retailer having your biggest sale of the year and your website crashes. Every minute you spend finding an authorized user is a minute lost, and when the internet is your business, time is quite literally money.

    Spread Recognition of Value

    No one wants their work to go unnoticed, but recognition is a learned practice and one that requires continued focus. DevOps teams and their work save their organizations vast amounts of time and money, and business leaders should take care to highlight the value of their team’s successes, both internally and externally. Not only does it encourage their teams to work harder and smarter, impacting the entire organization, but it also lifts up DevOps teams everywhere, publicizing best practices to outside teams and creating an exponential impact across the entire engineering community.

    Don’t Just Expect Change, Embrace It

    Innovation generally happens for two reasons: The tools being used to solve problems aren’t working, or the problems you’re trying to solve have changed. Every day, companies get frozen in time—the tools they use may work now, but the world around them is changing. It’s easy to get caught in a cycle of developing new products, but what if the tools your business uses to solve problems are out of date? When engineers make changes in the code, they must be in lockstep with every other department, from QA to customer service. Organizations that embrace change always will have a leg up on the competition.

    Capture Your Knowledge Base

    As business scales, their teams scale with them. What once may have been a two- or three-person DevOps team becomes a 40 person machine, and with scale comes a lack of coordination. More and more, DevOps teams are scattered across the globe, in offices and remote, and no two people have the same workflow. In this fragmented environment, it becomes imperative for companies to keep a store of knowledge their engineers can reference wherever they are, whenever they need to.

    Fostering a strong DevOps culture isn’t easy, but it’s necessary. At its core, DevOps is about collaboration and communication—companies that treat each team as separate units risk siloing their employees, creating closed information channels that are difficult to break through in times of crisis. Whether you’re pushing new code or bringing your business back online, timing is everything and engineers need to be able to move at the speed of business. These five tips won’t fix your code or craft new features, but they’ll certainly ease the process.

    — Dave McAllister

  • Blockchains Done Right Are the Next Evolution in Open Source

    Blockchains Done Right Are the Next Evolution in Open Source

    Open source code is more than just a way to create new technology. It’s a disruptive force that changed the way software is built, from taking individual developers and turning them into thriving communities to changing how enterprises do business–building open ecosystems versus restricted walled-gardens.

    The next evolution of this movement is blockchain technology. Decentralized groups of developers across the globe are contributing to greater data integrity for businesses, better guarantees to ecosystem partners and can work together on live instances including their data. And that was the missing piece–live instances. Up until now, we could only collaborate on writing the code for a system together. Today, with blockchain technology, we can also collaborate on running this system together.

    Open Source is Decentralized

    From its ideological beginnings in the 1980s, open source code changed how we do business around the world, all stemming from developers’ work in software creation. Developers have seen open source disrupting almost every field of infrastructure, from operating systems (Linux in the cloud) to databases (MySQL, MongoDB, Redis) to programming languages (JavaScript, Python, Java, C, PHP).

    Over time, open source connected thousands of developers and established a corporate precedent. In parallel, the largest corporations in the world are also the biggest contributors to open source. It is with these two transformations open source is now over 50% of all code relied upon in the average proprietary system in enterprise.

    Now, blockchain is disrupting existing business models by extending the implementations and possibilities of open software. It does so by providing a transparent and immutable record keeping method, auditability of algorithms, forking of live instances with the data and possibility facilitate governance participation, all derived from an open source, decentralized community.

    Amazon recently added support for open source blockchain frameworks such as Hyperledger and Ethereum on AWS. This is a great first step toward making this technology widely available. As more AWS blockchain customers build on the open source frameworks to build for enterprise business, the powerful capabilities of open source will become a part of the blockchain movement. Transparency, auditability and forkability in code, all present enormous opportunities for developers while also demonstrating a precedent.

    It should be noted where these instances run, whether on private permissioned networks or public permissionless ones, is material to their ability to provide external guarantees to their users. The highest standard of trust is permissionless–where any member of the public can participate in their operation and audit.

    Decentralization Rewards Both Developers and Enterprise Business

    Businesses have gained major advantages through the use of open source software. In the same way, decentralized blockchain infrastructure offers businesses increased security, robustness and most importantly, guaranteed transparency with its customers.

    Prior to the open source software movement, traditional methods of programming were expensive, slow to develop and lacked insight into user experience until long after each new release came to market. Today, developer communities download, interact and actively contribute to blockchain projects in the same way as open source. Decentralized developers give businesses rapid ability to replace arbitrary features with intentional decision-making by a large, merit-based community. Decentralized blockchains are Open Source 2.0.

    Today, most standard apps run with centralized back ends. The server hosts the back end and dictates how the database evolves, given users’ requests and transactions. End users interact through the front end and never see what’s going on behind their static experience. What if we gave users a way to shift the power structure inherent in this state? Apps could become better for their users and much more competitive.

    Not All Blockchains Fit the Open Source Credo

    There’s a wide spectrum in the industry with blockchain technologies ranging from fully public to completely private. There’s a lively debate whether the value given by these fundamentally different solutions is comparable. I argue that distributed ledger technologies or private blockchains have little technological innovation. Their validators are permissioned, which means they cannot provide unbiased external guarantees to their partners and users.

    That said, there are some benefits to using private blockchains in certain use-cases such as coordination between a small number of competitors or WalMart onboarding all its external supply-chain services onto one coordinated platform, but they are limited in giving any guarantees to anyone not participating in the consensus (i.e. not running a node).

    Public blockchains offer a business greater transparency, because there are neutral and external parties operating the blockchain outside of the company and its customers with an independent incentive system. This removes anyone’s opportunity inside the company to falsify records, as they could potentially do on a private blockchain, or have data integrity relying on business relationships and dependency. Public blockchains also live up to the ultimate test of trust–from the comfort of your home you can verify by yourself every guarantee provided by the network.

    Where Hybrid Blockchain Comes In

    Most public blockchains were designed for absolute decentralization, which makes them impractical for mainstream businesses. Private blockchains are highly practical but don’t offer the transparency and trust possible with public blockchains.

    Hybrid blockchains, such as the one developed by Orbs, offer the best of both worlds. They’re perfectly designed to address fundamental issues with performance and interoperability while allowing for applications in highly distributed environments. They provide strong guarantees, verifiable by anyone, yet leave businesses in control of their business models, governance and security.

    — Tal Kol

  • Debunking Myths Around RASP

    Debunking Myths Around RASP

    Runtime application self-protection (RASP) has taken a fair bit of scrutiny over the last few years. Like many security technologies that pioneer new ways of tackling old problems, people inherently don’t like change. Several companies entered the space early and early adopters helped mature various RASP solutions on the market and the technology has advanced rapidly.

    When applications began to be the favored target of bad guys, tons of companies started to reposition their perimeter security products closer to the application. Web application firewalls (WAFs) are similar to IPS for the network, so easy mind shift for most security practitioners. The problem is they require you to know your adversary. That’s like asking a security guard to keep out a single troublemaker, while letting in their associated gang of thugs.

    As we saw recently with WebLogic, exploiting applications is a shell game. When one vulnerability is exposed and patched, another one, which shares the same modus operandi, comes out. When reports came out comparing the most recent WebLogic vulnerability to vulnerabilities found last year in CVE-2018-2628, CVE-2018-2893 and CVE-2017-10271, Oracle posted a blog explaining last year’s vulnerabilities had been patched. The problem was the underlying code mechanism that led to the above-mentioned CVEs (insecure deserialization) had not been fixed.

    Deserialization is a perfect illustration of why RASP is the Chuck Norris of application security. Instead of applying a patch (which in the case of Oracle’s WebLogic, blacklisting the exploit method via a patch), RASP looks at the totality of the code before it executes and says, “If it looks like a duck and quacks like a duck, apply a roundhouse kick to the entire enumeration.”

    It’s important for enterprises to protect their customers from insecure deserialization with RASP products. Further, it’s critical to consider learning and debunking some of the common misconceptions in the overall perception of runtime security:

    Performance Impact

    Evaluate an agent-based solution, which often makes app owners concerned it’ll impact the performance of their applications. When evaluating RASP providers, especially agent-based solutions, ask for agent size, performance benchmarks and certainly conduct your own performance testing during evaluation.

    Writing Secure Code

    With the DevOps movement, companies have ramped investments in training and programs around secure development practices. And while security is shifting left with this movement, programming still has a little bit of art infused, especially when developing applications that have been around for a long time and have seen variations in development resources. As is the case with WebLogic, application developers should create apps with security in mind, but they don’t have a crystal ball and exploits evolve just as applications do.

    My Developers Will Become Lazy

    Somewhere in these early days of RASP, the notion came about that RASP means you no longer need to remediate vulnerabilities in your application source code. Notably, the root cause of all vulnerabilities should be fixed as soon as possible. However, RASP can also function as an insurance policy allowing DevOps teams to better plan fixes and prevent derailing other projects focused on the business.

    Why Do We Need RASP If We Have a WAF?

    The WAF has become ubiquitous in most organizations and it is certainly valuable for organizations looking to take a defense-in-depth strategy. WAFs have become a significant strain on resources as they produce unmanageable amounts of false-positives that require constant tuning. In a recent survey by Ponemon, it takes most organizations 45 hours a week to address alerts and 16 hours per week creating or updating rule sets.

    Hopefully, this article illustrates more color to today’s RASP. We’ve seen a lot of advancements in the early days of this technology and hopefully that will mean a lot less headlines.

    — John Adams