Tag: Platform

  • Nutanix Eases Development of IoT Apps

    Nutanix Eases Development of IoT Apps

    Nutanix, a vendor of hyperconverged infrastructure solutions, has released a new developer environment that allows developers to try and test IoT and AI apps in the cloud. Starting May 7, developers can sign up for a free 10-day trial of this experience.

    The developer environment is built under Nutanix’s Xi IoT Platform and gives developers access to a rapid development environment for creating internet of things and artificial intelligence apps in the cloud. The Rapid Development Environment for IoT includes features such as Xi IoT Cloud Instance, Xi IoT Sensor App and Xi IoT App Library and supports the ability to easily deploy IoT software in the cloud or at the edge, according to the company. The environment has been tuned specifically for IoT and AI, eliminating many of the configuration chores developers had to perform using other cloud-based development environments, and enables single-click deployment via a management console.

    For developers targeting production-edge environments, the new environment brings forth the ability to develop for the edge or for the cloud, bringing application portability into the development and testing process. By being able to use a common set of APIs, cloud and edge development becomes relatively seamless and deployment friction is vastly reduced, according to the company.

    Beyond ensuring compatibility across platform services and APIs, the environment enables development and production environments to use the same components, so recoding is not needed as part of the transition from dev to ops. That helps to simplify lifecycle management as well as fit agile practices better into the dev process.

    Nutanix also offers an extensive library of applications that can be used to ease development chores. The Xi IoT App Library offers  individual components (message bus services, time series databases, etc.) and full solutions that developers can use to address various business problems.

    Nutanix is framing the new delivery mechanism as a new experience to get more developers—from novice to advanced—creating AI and IoT scenarios.

    — Frank Ohlhorst

  • Blameless Launches DevOps Platform Based on SRE Principles

    Blameless Launches DevOps Platform Based on SRE Principles

    Blameless has emerged from stealth to launch a platform for managing DevOps based on the site reliability engineering (SRE) best practices defined by Google.

    Fresh off raising an additional $20 million in funding, the Blameless platform provides across-the-board visibility into the complex network of application programming interfaces (APIs) and applications distributed across an organization, said CEO Ashar Rizqi. Specific modules within the Blameless platform address incident resolution, reliability insights dashboards, postmortems, service level objectives (SLOs) and automatic error budget calculation.

    Blameless takes its name from an SRE principle that no one should be held at fault when complex systems fail. Rather, the assumption should be that inherent complexity of the IT environment is at fault. While DevOps is more of a philosophy surrounding the management of DevOps, SRE is emerging a more prescriptive instance of implementing DevOps that Google is now promoting. The goal is to make sure that whatever the issue, the right people to address it are brought together at the right time, said Rizqi.

    The Blameless platform was created by Lyon Wong, who now serves as the COO of Blameless. Previously, Wong was a partner at Lightspeed Venture Partners, founder of S28 Capital and a product manager for Microsoft Windows. Rizqi is a former head of core platform at MuleSoft and SRE manager at Box.

    Rizqi noted that while most organizations are trying to embrace DevOps principles, they often lack the tools needed to build the workflow processes required. All too often, organizations rely on little more than a Wiki document to manage their response to an incident. The Blameless platform is designed to provide access to an integrated set of tools for managing everything from the incident itself to the impact that event had on the business, he said.

    It’s still too early to say with any certainty how widely SRE practices will be adopted. This far, most organizations that have adopted DevOps have tended to prefer to define a set of processes that are customized to their environment. But there are just as many, if not more, organizations that have found it daunting to get started. Platforms such as Blameless represent an opportunity for those organizations to embrace DevOps using a more prescriptive approach.

    Of course, a big part of the reason that DevOps has been embraced unevenly by various departments within the enterprise is the lack of a consistent approach to implementing DevOps at scale. Teams that have embraced DevOps with enterprises have tended to create their own individual processes using a wide variety of tools. Many of those organizations have also found it challenging to get IT operations teams to embrace those processes because they require an approach that can be implemented consistently across multiple projects at scale. SRE provides IT operations teams with a framework that Google has already proven works at scale.

    Regardless of the path chosen, the one thing that is for certain is more agile approaches to managing IT operations will be required to keep pace with the rate at which applications are now being developed and deployed.

    — Mike Vizard

  • Why Banks Must Ditch the ‘Build vs. Buy’ Mentality and Embrace a Platform Approach

    Why Banks Must Ditch the ‘Build vs. Buy’ Mentality and Embrace a Platform Approach

    The past decade has seen digital transformation change nearly every aspect of our lives, and banking has proven no exception. Indeed, proprietary data from Avoka shows that in mid-2017, mobile overtook desktop as the most popular channel for applying for new deposit accounts at one top 10 U.S. bank. Banks have accordingly ramped up their IT departments and technology investments to adapt to this brave new world and digitize their offerings, with the aim of making their financial products just as accessible and convenient as products offered by tech customer service giants such as Amazon.

    The push to make banking products digitally ready (and very quickly) has spurred the old “buy versus build” debate in bank IT departments: Should we build our own digital onboarding software from scratch in-house, or do we buy off-the-shelf solutions from third parties that may be generic and not customizable to our brand and product offerings? While this dichotomy may have been a suitable mentality years ago at the start of the digital transformation revolution in banking, it no longer fits with the reality of today’s more complex development landscape and is starting to cause significant problems in bank IT departments.

    It’s no mystery that the majority of today’s banking IT projects use elements of both “build” and “buy.” But banks tend to opt for the “build” option in the main, reasoning that in-house development drives better outcomes. But this is a serious misconception—recent research from Forrester shows that more than half of all banking customer experience projects take longer than expected, leading to a blown project budget an overwhelming 88 percent of the time. A critical point: Projects using or re-using internally built components are far more likely to suffer these issues.

    This inevitably leads to a spiraling buildup of technical debt—a concept that banks should familiarize themselves with and treat just as seriously as actual debt (after it, it ends up in the bottom line—total cost of ownership is higher for internal builds around 64 percent of the time, as per Forrester’s research). A snowball effect takes hold: Projects with problematic delivery are far more likely to require endless catch-up fixes and high maintenance costs, draining time and resources from the development team that otherwise could be put to use on the increasingly crucial work of updating the offering to meet the continually evolving needs of the market and customers. On average, one-third of customer-facing software releases are updated only once a year or less, a number that rises closer to half for projects that are over-budget.

    Forrester’s research shows that this isn’t a matter of under-resourcing; teams report being allocated the right amount of time and resources. Rather, stumbling blocks stem from architectural inflexibility and poor technology, as well as changing business priorities sapping stakeholder enthusiasm and project velocity.

    Neither “build” nor “buy” in the older sense of the two approaches provide an adequate strategy for today’s development environment. The aversion to buying mainly took hold during a period when third-party products were fairly self-contained black boxes—off-the-shelf offerings that provided none of the flexibility of in-house and came at a cost to branding. However, this is no longer true of the third-party vendor landscape. The advent of platforms and APIs means it is now far easier for banks to bring in multiple fintech integrations to fill the gaps in their offering in a modular, “mix and match” manner—all fully customizable, extendable, flexible and capable of being brought together on an organized, neat platform.

    Banks need to embrace this change and ditch the old “buy versus build” debate that so often prioritizes internal builds as a knee-jerk reaction. The constraints of the old build or buy choice means that the tendency is still to think of digital transformation as a series of off-one projects, when the most successful efforts treat it as a holistic, continuous evolution. After all, customer needs and expectations are constantly evolving, and so should customer-facing software.

    So, how should bank development teams and their stakeholders approach a new digital transformation project? The answer lies in BBEA: Buy, Build, Extend and Assemble. The rule of thumb here is that where services and capabilities are generic and not unique to the bank, they should be sourced from expert vendors with a proven ability to get the job done quickly and in an expert manner (why incur a longer development cycle and higher TCO by reinventing the wheel and building internally?). This frees up the bank’s own internal resources to work on building elements that are truly unique to the bank’s value offering. While it used to be prohibitive to pursue both of these approaches simultaneously, this is precisely what the new world of APIs and platforms enables.

    Sourcing and extending components in this way reduces technical debt significantly, and spreads the cost of R&D across external players. The platform approach makes it far easier for banks to tailor these external components to their own brand and specific circumstances, and makes adaption to changing future needs far less onerous, removing the tendency to revert to big and costly start-from-scratch projects on a regular basis.

    Banks that want to get ahead in their digital transformation strategies must their ditch old development habits and embrace the new platform approach. Buy vs. build is dead; long live BBEA.

    — Steve Demchuk

  • Redefining Product Value in the Continuous Economy

    Redefining Product Value in the Continuous Economy

    The internet is now more than 20 years old. It’s older than my kids, which is a scary thought. It’s older than Kendall Jenner. It’s older than Uber, Grey’s Anatomy and the iPhone. And so now, after more than two decades of software and e-commerce, it’s high time we take stock of where consumers really are today.

    First, consumer expectations are shifting dramatically. The digital world has brought a whole host of changes in how people work, shop, interact and engage with businesses.

    Second, the notion of brand loyalty has dissolved, shattered beyond recognition.

    And, third, this utter lack and loss of loyalty puts companies at an insane disadvantage. We’re living with a “see you later” digital mindset, where it’s easy to say goodbye to something you know online for an opportunity with the newest, next-best thing.

    All of this means that companies must deliver a constant stream of software that is fluid, flexible and competitive to gain and retain customers.

    It also means that companies absolutely must understand how consumers weigh and determine product value today, because, quite clearly, buyers aren’t making product choices in the same ways anymore.

    Indeed, 20 years ago, customers chose products based on product features. Today’s modern consumers are continuously looking for new products, embracing them and then discarding them for something even more new. In fact, the willingness to switch is so strong, according to Harris Interactive, that 86 percent of consumers quit doing business with a company because of a single bad experience. And 90 percent say they would be willing to pay more for the same product if they received a more positive purchasing experience.

    This continuous process of discovery, adoption, discarding, discovery, adoption, discarding, discovery, adoption and discarding tells us—very loudly and unequivocally—that value isn’t in the actual product itself, but in our ability to continuously evolve the product.

    Shifting Consumer Expectations Require a Continuous Approach to Business

    If you can’t continuously transform the way you deploy your product, people and processes, there’s no way you can keep up with customers’ “see you later” mindset and their continuous discovering, adopting and discarding of products.

    Two decades ago, for example, you chose a car based on ideal product characteristics (make, size, etc.) and how much you could afford to spend. Your choice would live with you while you paid it off or until you could justify changing it.

    Now, software and the speed of innovation have allowed consumers the opportunity to make product choices at a greater frequency. Instead of only getting the newest features when you buy a new car every 10 years, car operating systems are updated wirelessly and provide the latest and greatest features to existing owners, without the need to buy a brand new vehicle. The car has become a software platform.

    Even the physical choice of platform (the car itself) is beginning to change. For those who wish to change their car regularly, there are many services (such as Zip Car) that allow you to rent access to a car and return it when you’re done. Or even not to drive at all, with the advent of software companies such as Uber and Lyft.

    Obviously, each product—software or otherwise—must have a set of threshold features, or else consumers won’t choose it. A car, for example, needs to be waterproof with airbags and ABS brakes. And a task app needs to allow you to add appointments and meetings to your calendar. But to be competitive today, products must now also include the ability to switch away from features and add new ones seamlessly.

    Value is Driven by Option

    This “optionality” drives product value in what has become the ‘continuous economy’ of 2016. Companies can deliver “optionality” only by eliminating barriers from their production processes.

    Companies need to adopt product development processes that are lean and high velocity to provide customers with an ongoing series of new product features and choices. That’s why you need to continuously deliver and continuously change your software.

    Keeping Pace with the Acceleration of the Continuous Economy

    If you can’t—or won’t—continuously transform innovative software products and the way you produce them, you won’t be able to compete in today’s quicksilver-fast marketplace.

    Or, to put it more broadly, software, as well as the organization and its people and processes, must be able to pivot with agility in what seems like a nanosecond to keep pace with the acceleration of the continuous economy.

    This is all very different than what we’ve experienced in the past.

    Two decades ago, an organization confronted a new competitor or change in the market, by developing and deploying new operations, organization adaptations or products to meet the challenge.

    Today, software is the primary route to market, so companies must continuously develop and deploy new software as part of an always-transforming organizational culture. If you’re unable to develop and deploy on a sustained basis in today’s continuous economy—if you only transform on a selective basis—you won’t be in business very long.

  • DevOps and PaaS: ‘Give me a platform. Let’s rock, let’s rock, today’

    DevOps and PaaS: ‘Give me a platform. Let’s rock, let’s rock, today’

    Give me a platform. Let’s rock, let’s rock, today.

    – Dewey Finn, School of Rock

    The term Platform as a Service (PaaS) has become overloaded to define any ‘platform’ that provides ‘services’ to its users. The term PaaS is formally defined by NIST as:

    “The capability provided to the consumer is to deploy onto the cloud infrastructure consumer-created or acquired applications created using programming languages, libraries, services, and tools supported by the provider. The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, or storage, but has control over the deployed applications and possibly configuration settings for the application-hosting environment.”

    – The NIST Definition of Cloud Computing, NIST, US Department of Commerce, Sept. 2011

    Like most terms in the IT industry (or to really generalize, the human communication medium known as language), PaaS is overloaded, overused and misunderstood. A quick web search or even a visit to the Wikipedia page on PaaS proves my point.

    I prefer to look at such overloaded terms in context. In this post I am going to look at PaaS thru the lens of DevOps (no surprise to a reader of this website). I will explore what it means to an organization looking to adopt DevOps and leverage the services offered by utilizing a PaaS platform. I will explore and contrast a ‘build your own’ in-house platform as a Service or a subscription based commercial PaaS offered by a vendor. I will use PaaS offerings from IBM to illustrate my points. (Disclosure – IBM pays my mortgage).

    Lets start.

    Defining PaaS:

    The most critical section of NISTs definition of PaaS, that differentiates PaaS from an ‘Infrastructure as a Service’ (IaaS) consumption model for cloud is:

    “… The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, or storage, but has control over the deployed applications and possibly configuration settings for the application-hosting environment.”

    This picture better illustrates the differences.PaaS-IaaS

    As you can see in this picture, what distinguishes the two cloud adoption models – IaaS and PaaS – is how much of the stack is managed by the user (or client) vs how much is managed by the Cloud Platform provider. What is important to highlight is two things:

    1. Every capability in the stack is available as a managed service – this would be a shared, multi-tenant, service available to users, with the underlying implementation abstracted from the user
    2. The Client/user only has to be concerned about managing their own applications, data and user access, leveraging the services available on the platform, which manages the rest

    Platforms as a Service may be either public (IBM BlueMix, CloudFoundry from Pivotal, Google App Engine, etc) or private (hosted CloudFoundry; self built and hosted platform). Organizations may also build their own hosted and managed leveraging multiple technologies, self hosted on a private cloud. For a private instance of course, the organization hosting it in their own data center would be responsible for managing all the services hosted on the platform. Building a PaaS on an IBM PureApplication System, would be a good example.

    DevOps and PaaS:

    When one looks at DevOps on PaaS one has to look at the services that need to be hosted on the platform in order to implement a DevOps services platform. If one looks at a DevOps pipeline and the core components that make up a delivery pipeline up, each of the components need to be available as a service, in order to provide a complete ‘DevOps on PaaS’ solution. Namely:

    DevOps Services

    • Development tools as a service (and/or an ability to connect the services on the platform to a desktop IDE)
    • Build as a service
    • Deploy as a service
    • Test as a Service
    • Monitoring as a Service

    These would be what one refers to ‘DevOps Services’.

    In IBM’s new PaaS offering – Codename: BlueMix (in open beta), these DevOps are services are an inherent part of the platform. There services on Bluemix are:

    • Git hosting as a Service
    • Web based IDE
    • Agile planning & tracking, team collaboration as a Service (Jazz.net)
    • Mobile Quality Assurance (MQA) as a Service
    • Continuous Integration as a Service (Jenkins as a Service)
    • Deployment Automation as a Service (powered by UrbanCode Deploy)
    • Performance Monitoring as a Service

    These capabilities working in concert, provide a Continuous Delivery Pipeline on IBM Codename: BlueMix.

    DevOps as a Service (DaaS?)

    So, to conclude. The value proposition for adopting a PaaS platform is self-evident. If you are an organization that delivers software, and is looking to adopt DevOps, a PaaS offering that includes DevOps services allows you to adopt DevOps at a very low cost of entry. You do not need to craft a Delivery Pipeline and implement the whole Continuous Delivery toolchain. Integrations, hosting, servicing – not your problem. Pay-as-you-go, and allow for scale. It is however, not a viable option for all organizations, as it is a drastic shift in corporate culture and potentially policies. Especially if you look at a public PaaS. If you are a born-on-the-web organization, or an enterprise with born-on-the-web applications, you should take a closer look. Check out Codename: BlueMix at www.bluemix.net.