devopsy.kinsta.cloud

Tag: cloud services

  • Why an Enterprise 5-Year Cloud Plan Must Focus on Serverless

    Why an Enterprise 5-Year Cloud Plan Must Focus on Serverless

    While most of us have looked at the beginning of the new year as the time to set our personal resolutions for the next 12 months, enterprises have already started to execute their plans for the year ahead. But, that’s part of a problem. Too often major organizations move from year to year on a schedule of 12-month technology plans, never really planning or setting a path for ambitious change that will be realized in years two through five. Thinking in terms of 12-month plans, rather than a desired end state in three or five years, creates a missing-the-forest-for-the-trees effect, where enterprises can end up chasing the technology trend du jour and miss taking advantage of major disruptions to their industry.

    We saw this with the cloud: Many enterprises, still focused on improving virtualization, were surprised by how quickly their developers took to the cloud to develop new applications. These same organizations have factored the cloud into their long-term planning now, but only after many others have reaped the advantages and proven it to be a great way to deliver rapid innovation. And, so far, enterprises look to be on the verge of making a similar mistake with serverless computing.

    Serverless: The Ultimate Abstraction Layer

    Many developers are increasingly looking to serverless computing as a faster way of developing and deploying business IT workloads. It’s not difficult to see why: Developers focus on their application and run it with third-party management; their code is only executed when prompted by predetermined triggers; it scales automatically as needed; and the business is only charged for the time that that code is actually running (as opposed to a flat rate, regardless of whether the code is running). This seems like the kind of intuitive no-brainer that enterprises should be setting a path to now.

    Serverless computing is the natural outcome of the past decade of IT development, where we’ve seen different kinds of layers of abstraction being applied to hardware to create innovative new forms of growth, and do so at scale. Those layers run the gamut of:

    • Virtualization, used to consolidate multiple virtual machines across a single hardware platform;
    • The cloud, used to virtualize compute, networking and storage; and
    • Containers, used to isolate application technology components that can be deployed and operated at scale across multiple substrates.

    Following that evolution, we now have serverless computing, which takes code and functions, and executes in an environment that takes care of all the underlying infrastructure, everything from application services through operating systems, hypervisors and hardware. In other words, the ultimate abstraction layer.

    Embracing Serverless Means Rethinking IT

    Previous abstraction layers, such as the cloud and containerization, broke out as disruptive technologies and caught a lot of enterprises flat-footed—they hadn’t been planned for well enough in advance. Organizations needed to adjust to incorporate them into their IT workloads and business models after the fact to try and give their developers what they wanted and avoid falling behind. Consider the disadvantage that places them at when compared to cloud-first—and, increasingly, cloud-only—organizations.

    Serverless promises to be even more disruptive, in no small part because it isn’t just a new layer to add on top of your hardware, as containers and the cloud were. Incorporating serverless computing into your IT environment requires a complete rethink of how your IT workloads are structured, because the serverless approach works by forcing organizations to focus on business technology as application code and not be distracted by the commodity services needed around it.

    All the more reason why enterprises need to get serious now about making a long-term plan for IT that revolves around serverless computing and outsourcing IT infrastructure. Preparing for a world where the default for new applications is to be developed to run against serverless platforms will take several years. And, in fact, delaying too long will only open you to some of the challenges presented by serverless adoption: application portability, service predictability and overall failure liability.

    Enterprises are understandably wary about outsourcing too much of their IT infrastructure, but the fact is, this is the direction the world is moving in. And besides, serverless isn’t solely a service offered by external cloud providers. There are many serverless platforms, such as Galactic Fog, that can be run atop of fully managed Kubernetes or OpenStack on-premises infrastructure and deliver the same benefits. Companies will only continue to outsource more and more of their IT infrastructure one way or another through 2018, putting us on track for entirely serverless businesses in just five years’ time.

    While everyone is thinking about the year ahead, enterprises need to think about the next five years, whether their IT infrastructure as-is is making a difference to their business and how they can—and need to—restructure accordingly to best leverage serverless computing to their benefit.

    — Mark Baker

  • SAP Cloud Price Changes Reflect DevOps Realities

    SAP Cloud Price Changes Reflect DevOps Realities

    To foster more application development in the DevOps era, SAP at the Mobile World Congress 2018 conference announced it is adding a consumption-based pricing option to its SAP Cloud Platform environment.

    Based mainly on the Cloud Foundry platform-as-a-service (PaaS) overseen by the Cloud Foundry Foundation, the SAP Cloud Platform provides a way for SAP customers to build custom applications that can be more easily integrated with SAP applications delivered as a cloud service using a standard set of application programming interfaces (APIs). The basic idea is to enable organizations to innovate in a way that doesn’t impact their applications every time SAP, for example, updates the SAP S/4 HANA application portfolio, said Dan Lahl, vice president of product marketing at SAP.

    SAP Cloud Platform currently is made available via a set of services an organization subscribes to for a defined amount of time. Under the consumption approach, an organization buys credits that can be applied within a specific amount of time. That makes it more economical for organizations to start multiple custom projects without having to know precisely upfront what services will be employed on the SAP Cloud Platform, Lahl said.

    In effect, SAP is creating a licensing model more in keeping with how developers consume services in the age of DevOps, he noted.

    SAP also announced an enhanced SAP Cloud Platform SDK for iOS, providing tighter integration with the Apple Xcode integrated development environment (IDE) and additional analytics controls that can be embedded within an iOS application. SAP has also made it easier to consume SAP Leonardo services for building internet of things (IoT) applications using APIs that can be accessed via the SAP API Business Hub.

    Lahl said in the coming months SAP also will share with customers best DevOps practices it follows to develop and maintain cloud applications. SAP is now seeing traditional IT organizations now starting to more aggressively adopt DevOps processes, he said, primarily because DevOps processes enable IT organizations to show a proof-of-concept (PoC) to line of business executives much faster. That, in turn, also serves to condense the feedback loop between business units and the internal IT team.

    Those projects now span multiple classes of runtimes, including SAP ABAP, Java and Docker containers—all three of which are being employed to create microservices. The challenge many organizations now face is determining when to build a microservice versus invoking a function via an API that already exists in an ERP application. Application developers don’t often have visibility into an existing function, which is why they run into resistance from business executives whenever they attempt to reinvent a wheel that already exists, Lahl said. The challengeis making it easier to discover the APIs that expose functions within an existing monolithic application, especially when it doesn’t make sense to reconstruct a general ledger function as a microservice.

    Whatever the ultimate approach employed, the one thing that is clear is that costs associated with either building or consuming a service keep coming down in the age of DevOps.

    — Mike Vizard

  • Is DevOps Ready for a ‘Steam’ Moment?

    Is DevOps Ready for a ‘Steam’ Moment?

    It’s hard to believe we live in a world where a game such as “Goat Simulator” can manage to find an audience in an industry brimming with AAA titles including “Destiny 2,” “Overwatch” and “Call of Duty,” but we do. “Goat Simulator” was a massive success, but none of that would been possible in a pre-Steam world.

    Before Valve launched Steam Greenlight, and subsequently Steam Direct, the indie game community was a shell of what it is today. The path to market for independent game developers was very limited up until that point, allowing the likes of Electronic Arts, Square Enix and Nintendo to dictate the future of the industry as a whole. While only apparent in hindsight, the state of the market wasn’t only impacting game developers, it was limiting the choices of the gamers themselves.

    The state of cloud services today is almost identical to what we saw among indie game developers prior to the launch of Steam Greenlight. Amazon, Microsoft and Google have established a cloud monopoly, but they don’t have a monopoly on innovation. This has forced developers to play by the monoclouds’ rules and live within their walled gardens, sacrificing quality and performance for cost and convenience.

    Related Content:

    Operations Management Puts the ‘Ops’ in DevOps

    Resource Availability: The Missing Piece of the Cloud DevOps Puzzle

    This ultimately undermines the prime directive of DevOps, by limiting an organization’s ability to map software investments and architecturing to its business objectives. The phrase “one size fits all” has no place in the world of DevOps, but if Amazon and the other cloud titans have their way, Dev and Ops teams will have no choice but to do their best with an increasingly ubiquitous set of solutions.

    Sure, there are breakout success stories among developer service startups including Twilio, MongoDB, New Relic and SendGrid, but for every developer service that manages to get off the ground, there are at least 10 that die on the vine. Why should the future of the cloud, which is arguably the biggest technological advancement since the internet, be shaped by companies known for retail, search and hardware? It shouldn’t.

    Developers need their own Steam moment, and it wouldn’t just benefit DevOps teams, it would benefit businesses and make the market more competitive overall. The developer equivalent of “Goat Simulator” is out there, waiting to go viral, except instead of letting you control a four-hooved wrecking ball, it lets you hunt down expensive N+1 queries or configure RabbitMQ clusters.

    Get Ready for the Steam Moment

    So what does developer’s Steam moment look like? It all starts with discovery.

    Developer startups will never be able to compete with the economy of scale that a company such as Amazon possesses. The resources behind AWS allow the company to pump out comparable solutions to emerging developer favorites before they have a chance to reach a mainstream audience, which results in the death of far too many promising startups. Even with superior technology, they simply can’t keep up with Amazon’s spend on sales and marketing, which allow them to manufacture user bases overnight. If we applied this state of affairs to gaming, and Steam hadn’t existed in 2014, games such as “Goat Simulator,” “PLAYERUNKNOWN’S BATTLEGROUNDS” or “Stardew Valley” would have easily been co-opted by a major game studio right when they were on the verge of taking off.

    To correct course, cloud service startups need a platform for connecting them with their audience, whether they offer a solution that will be useful to 100 or 100,000 developers around the world. However, to make this possible, developers and operations teams need to gain a voice during the procurement process before their executives make their way to AWS re:Invent to be wooed by flashy sales pitches and $50 steaks.

    But, that is only step one. DevOps teams need to do their research and point management toward solutions that reside outside of the monocloud hierarchy. Even if the developer equivalent of Steam exists, that doesn’t guarantee non-technical executives will find it, which is why developers not only must vocalize the solutions they need, but also where to find them. Contrary to popular belief, even if you build it, they don’t always come, and if the developer community remains quiet, we can forget about having our own Steam moment.

    I’m glad we don’t live in the timeline where a goat simulation can turn into a viable business, and hopeful our cloud future won’t be dictated by the likes of Amazon and Microsoft. Our Steam moment hasn’t happened yet, but if developer and operations teams join forces to demand a better alternative to the one-size-fits-all approach, it could be just around the corner.

    — Peter Cho

  • IBM Looks Toward Cloud Unification

    IBM Looks Toward Cloud Unification

    Now that IBM is achieving some critical mass in the cloud, the next major focus will be unifying the management of disparate cloud services.

    IBM recently reported revenue of $79.1 billion for its most recent fiscal year, a decline of 1 percent year over year. But within that revenue mix, Big Blue also reported that cloud revenue now accounts for $17 billion, an increase of 24 percent year over year. All told, cloud services now accounts for 21 percent of IBM’s revenues, and the company’s “as-a-service” annual exit run rate was $10.3 billion, up 24 percent year over year. Those revenues include $9.3 billion delivered as a service and $7.8 billion for hardware, software and services.

    IBM may not be in the same league as public cloud service providers such as Amazon Web Services (AWS). But the company is in a unique position to unify the management of public and private cloud computing services, said Rob Thomas, general manager for IBM Analytics.

    Most organizations are implementing a multicloud computing strategy. That decision creates significant data management issues that need to be addressed by a more holistic approach to DevOps, Thomas said, noting that IBM is betting that being able to consistently port applications and data between clouds will emerge as major theme in the enterprise in 2018 that it is in a unique position to address.

    Rob Thomas, IBM

    Today, most organizations are managing each cloud service they engage in isolation. But, rather than decreasing costs, each cloud service engaged brings with it additional overhead. In fact, each new cloud service conspires to increase the total cost of IT ownership for IT organizations as they move to master the tools required to support it. Despite that issue, the inherent business and IT agility cloud services provide are too compelling to ignore. Thomas said the result will be a continued proliferation of cloud services that enterprise IT organizations will want to unify under a common data strategy that also extends to their legacy IT environments. Otherwise, there ends up being too much duplication of data and effort, he said.

    Much of the effort to centralize the management of multiple cloud begins and ends with sound DevOps practices. The need to centralize the management of multiple clouds goes well beyond simply achieving cost synergies. Managing public and private clouds alongside legacy applications won’t be sustainable unless organizations modernize how they build, deploy, update and manage applications, Thomas said. Given the fact that each of those applications in turn increasingly will be made up of multiple microservices, modernizing the way the data that each of those services can access by extension also becomes critical, Thomas noted.

    Of all the major cloud services providers, IBM is the only one focused on providing the tools and services needed to help IT organizations make that transition at the level of scale required, Thomas said, noting that, in addition to a raft of DevOps and data management tools IBM provides, the company has extended the DevOps managed services it provides to enable organizations to accelerate that transition.

    It’s too early to say just yet how the rise of multicloud computing will transform enterprise IT. But it’s clear the days when the local data center was the primary focus of enterprise IT are long over.

    — Mike Vizard

  • 5 Reasons AWS Service Catalog is Sexy for DevOps and Cloud

    5 Reasons AWS Service Catalog is Sexy for DevOps and Cloud

    Ok, so you’re probably more excited about topics such as microservices and containers right now, but bear with me. AWS Service Catalog is becoming increasingly necessary as cloud infrastructure evolves, allowing IT and developers to share pre-approved services, which helps tear down silos and encourage DevOps-related practices.

    If you’re not familiar with Service Catalog, it allows organizations to create, manage and share catalogs of IT products and services that are approved for use on AWS. You can share simple services, such as an Amazon S3 bucket, or more complex services, such as a multi-tier application containing an auto-scaling group and Amazon RDS with Amazon DynamoDB tables. Amazingly, the end user can provision these services without knowing the complexity behind the AWS services, and if you wanted, without needing write permissions to AWS (more on this later).

    Further, Service Catalog is built on top of AWS CloudFormation, which means that when you design services and follow security best practices and run time, you can add constraints such as controlling instance sizes (I know, everyone loves to launch the biggest instances).

    In this blog post, I’ll share five reasons why you should consider making Service Catalog part of your DevOps and cloud strategy right now.

    Improved Security

    As a sysadmin 10 years ago, I remember our department had full control of bringing all new resources to the infrastructure. We’re fortunate that’s no longer the case and its typical for developers to provision resources.

    Provisioning resources on AWS has never been easier, but many developers who can provision resources have limited understanding of the AWS shared security model. For example, a recent Uber hack was due to someone checking the keys to GitHub. What’s more, the steady and impressive flow of new services from AWS makes it even more difficult to know and follow security best practices for provisioning resources for various services.

    Service Catalog can help improve security. Here’s how:

    • Have developers provision resources without having access to AWS. Yes, you read that right: You can add constraints regarding which IAM role should be used to provision resources.
    • Build your service catalog on top of CloudFormation, which means you can follow the security best practices once, such as enabling data encryption at rest encryption for S3. So, when your users provision resources, all these best practices are applied.

    Cost Savings

    In Service Catalog, you can add constraints on the size resource allowed for provisioning (love the extra-large instances). Your developers can still provision resources, but they’re not going to break the bank. And your CFO will love you for that.

    Using constraints you can control instance type to be either t1.micro or m1.small

    Centralized Management of Service Catalog Across Accounts for Better Compliance

    Although Service Catalog is built on top of CloudFormation, unlike CloudFormation it’s designed for sharing commonly deployed applications to promote collaboration. This means you can share the service catalog across multiple accounts and have the same constraints copy over. Here’s a great article on how to do that.

    Productivity Gains

    Most often I work with companies on Service Catalog to increase productivity. One of the common objections I get is, “We’re not ready for this level of standardization because our infrastructure is changing so fast—we’re in rapid change mode.” Fair enough! However, even during this rapid development phase, your developers are most likely, individually rather than collectively, working on standardization to increase productivity. As an example, let’s say I normally launch a test server that updates the security group with access to VPN. Chances are there are other developers taking similar actions by writing their version of scripts. This is precisely where Service Catalog helps, by providing the platform to share these types of services (such as launching a server with VPN access only) to other employees, which, in return, improves team productivity.

    Facilitating DevOps Culture

    A principal objective of DevOps is to break down silos and align team members around delivering customer value. Service Catalog encourages a culture of sharing and collaboration by instantiating it into practice.

    What’s Next?

    I’m excited about the capabilities of Service Catalog and its promise for DevOps teams. At nClouds, we’re taking our use of Service Catalog to the next level by integrating an approval process to govern provisioned services, and automating the workflow as part of the change management process. Automation and just-enough lightweight process provide the control needed, but without sacrificing DevOps speed. You can read more in this new white paper, “Modern Change Management for AWS.”

    Also, for more information about Service Catalog and DevOps in practice there are some great presentations from AWS re:Invent available for replay: financial services FSV308, Fannie Mae MSC201, and John Wiley & Sons DEV321.

    — JT Giri

  • How DevOps is Vital for SaaS Entrepreneurs

    How DevOps is Vital for SaaS Entrepreneurs

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

    Integrating DevOps into the SaaS Product

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

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

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

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

    Advantages of DevOps Automation

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

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

    Rapid Delivery of New Code

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

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

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

    Using DevOps to Provide a Better SaaS Experience

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

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

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

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

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

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

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

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

    In Conclusion

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

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

    — Subramonian

  • What Developers Want, and How to Give It to Them

    What Developers Want, and How to Give It to Them

    Software is at the core of every modern business, and software-driven companies are disrupting most traditional industries. As the demand for rapid delivery in digital services grows, companies are looking for ways to release products and upgrades in weeks instead of months, or in days instead of weeks. Many DevOps groups are adopting the continuous integration/continuous delivery/continuous deployment cycle of Agile software development to address the high velocity of releases and faster time-to-market requirements. In the CI/CD/CD cycle, developers and testers continuously integrate and test new code, deliver applications and upgrades to production, and from there, deploy them to customers through cloud- or web-based venues.

    But in most companies, dev/test teams are dependent on IT and operations (IT Ops) teams to provide the physical and software stacks they need, and IT Ops teams can’t provide developers and testers with infrastructure and applications fast enough to meet the ongoing and relentless pace of the CI/CD/CD cycle.

    DevOps Challenges

    The most common IT Ops obstacles are long procurement and provisioning cycles, lack of automation and organizational silos.

    Long Procurement and Provisioning Cycles: In many software companies, the IT Ops team has a lengthy procurement and provisioning cycle, and developers may have to wait anywhere from several days to a few weeks for IT Ops to handle each request.

    Lack of Automation: Developers may be using an outdated IT ticketing system to request infrastructure and software. Each time a developer issues a ticket request, an IT Ops person must follow a certain workflow to fulfill that request, and must complete each step before sending the ticket on to the next IT Ops person in the chain. These workflows often consist of time-consuming manual steps. For example, an IT admin may spend hours manually copying database software from a file server over to the hardware using command line interface (CLI) scripting. The admin must then install and configure the database software and connect it to the network.

    Organizational Silos: In large enterprises, individuals or sub-teams fulfill certain tasks for a dev/test request separately from the others. These silos turn IT Ops procurement into a long series of handoffs, where each team member must complete their assigned tasks before handing the job off to another team member.

    What’s a company to do? The answer is to implement a self-service, automated private or hybrid cloud. Here are some of the reasons for this approach.

    On-Demand, Self-Service Provisioning

    Every developer is different, and each should have the power to create their own workspace. A self-service cloud automates the provisioning process by letting developers and testers manage their own initial deployments and configurations. The cloud platform should offer a set of automated provisioning tools to allow developers and testers to create their own dev/test environments. The cloud solution should include both a self-service user interface and an API-driven infrastructure-as-code that lets developers create VMs and databases, access storage, set up network connections, etc., using RESTful API coding.

    An Intelligent, Well-Organized User Interface

    A self-service cloud should have an intelligent user interface (UI) that gives developers access to a set of common infrastructure tools and applications. Ideally, a self-service UI should allow IT Ops administrators to assign resources in an organized manner. Admins should be able to designate business units (BUs) on the UI (i.e. “AppDevTeam1,” “WebDevTeam1”) based on units within the company, assign team members to BUs, and designate current projects (i.e. “AppDevProject1”) on the UI according to BU. They should also be able to assign quotas to each BU (i.e. AppDevTeam1 gets 100 VMs, 25 vCPU cores, 100GB memory and 400GB storage), and to each individual project (i.e. AppDevProject1 gets 10 VMs, 5 vCPU cores, 8GB memory and 40GB storage).

    An Application Store

    A self-service private cloud should have an online “application store” that provides single-click access to common tools and services for CI/CD, workload management, middleware and storage back-ends.

    Seamless, Two-Way Hybrid Cloud Migration

    A self-service hybrid could should have seamless, two-way migration to allow developers and testers who have public cloud access to easily move applications and workloads back and forth between public and private clouds.

    Administrative Dashboards

    A self-service cloud should have a set of administrative dashboards that allow the IT Ops team to control access to resources on the UI. These dashboards should deliver complete visibility into which teams and team members are using which resources, and allow the IT Ops team to perform admin tasks such as:

    • Creating user accounts and passwords on the UI
    • Creating BUs, and projects for each BU, on the UI
    • Assigning developers and testers as “members” of a certain BU or project
    • Assigning self-service infrastructure tools (compute, storage, network) on the UI, and set quotas for those tools according to BU or project
    • Importing new applications to the application store or the UI.

    A Software-as-a-Service Platform

    A software-as-a-service (SaaS) platform with portal-based access is the best venue for a self-service cloud solution. A SaaS platform offers the flexibility to do upgrades and customization to the various features of the UI, application store and administrative dashboards. The flexibility of the SaaS private-cloud solution gives it the potential to become the de facto standardized platform for CI/CD/CD in Agile software development.

    In short, DevOps teams need to keep up the CI/CD/CD pace in a modern enterprise, and self-service cloud platforms offer the self-provisioning and customized workspaces that keep developers productive and happy.

    About the Author / Kamesh Pemmaraju

    Kamesh Pemmaraju leads product management, product marketing, and technology partnerships at ZeroStack. Kamesh is a seasoned product management/marketing leader with a strong engineering and consulting background. In his most recent product roles at Mirantis and Dell, he focused on delivering private and hybrid cloud solutions to enterprises. He holds a Master of Science in Computer Science from Indian Institute of Science. Connect with him on LinkedIn and Twitter.

  • VMware Adds vRealize Automation to Cloud Platform

    VMware Adds vRealize Automation to Cloud Platform

    At the core of the VMware approach to cloud computing is a VMware Cloud Foundation platform that combines storage and network virtualization software with the company’s core hypervisor platform. Now via the release of VMware Cloud Foundation 2.3, integration with the VMware vRealize portfolio of IT automation software is being added.

    Matt Herreras, director of product marketing for VMware, says the inclusion of VMware vRealize Automation, vRealize Operations and vRealize Log Insight will make it easier to deploy application workloads on a platform that VMware manages on behalf of customers, whether it’s deployed on-premises or in a public cloud.

    IT organizations will also be able to use the management console VMware provides with VMware Cloud Foundation to configure the vRealize automation framework.

    At the same time, VMware is adding support for heterogeneous servers within a single rack, including be able to specify specific servers for each workload domain.

    Additionally, VMware has revealed it is working with Intel to include the latest family of Intel Xeon Scalable processors in an existing Intel Select Solutions for VMware Cloud Foundation program. Those processors are expected to be certified in the first half of 2018.

    VMware Cloud Foundation is rapidly becoming a centerpiece of the VMware approach to DevOps. VMware claims that a VMware-based cloud can be spun up six to eight times faster using VMware Cloud Foundation, while total cost of ownership of a private cloud will drop 30 percent to 40 percent and administrator productivity will increase by a factor of two.

    IT organizations that have standardized on VMware are under significant pressure from developers to become more agile. In many cases, those developers end-run the internal IT organization by programmatically invoking cloud services, even if it would be more cost-effective for the application workloads to deploy locally. The challenge those administrators and VMware both face is convincing developers that VMware environments are flexible enough to meet their need to access IT infrastructure on demand, now that an IT automation framework has been tightly coupled with VMware Cloud Foundation.

    In the meantime, VMware is also betting that as large numbers of existing applications are lifted and shifted into the cloud, most IT organizations would prefer to not have to refactor them. To allow IT organizations to avoid that issue, VMware is making VMware Cloud Foundation available jointly with Amazon Web Services (AWS), while partners including IBM provide their own managed instance of VMware Cloud Foundation. Herreras notes that the VMware vRealize automation suite also includes tools for managing AWS and Microsoft Azure environments as an extension of a local VMware environment.

    In addition, VMware has invested in container technologies including Docker containers and Kubernetes clusters, which can be deployed on VMware. Herreras says that from an IT operations perspective, the company is betting that most IT organizations will prefer to deploy legacy monolithic applications and emerging microservices applications on top of a common base infrastructure to minimize costs.

    It might be a little while longer before VMware can completely pull all the elements of its DevOps strategy together. But the one thing that is clear is that, at the very least now, the company understands just how much of its continued future relevance in enterprise IT is at stake.

    — Mike Vizard

  • Cloud Orchestrators: Beneficial in a Multi-Cloud Environment

    Cloud Orchestrators: Beneficial in a Multi-Cloud Environment

    Recent outages of leading cloud providers affecting thousands of business worldwide, such as the Amazon Web Services S3 outage that occurred in late February, have forced many CIOs and CTOs to think hard about their cloud strategies, including whether a multi-cloud environment would be of benefit.

    ROI and Business Impact

    During AWS’ four-hour disruption, S&P 500 companies lost $150 million to $160 million, according to analysis by Cyence, a startup that models the economic impact of cyber risk.

    Web monitoring company Apica, which watches internet performance issues worldwide, discovered that 54 out of the top 100 internet retailers were impacted with a decrease of 20 percent or greater in performance, and three websites went down completely—Express, Lululemon and One Kings Lane—resulting in a high impact in business.

    During this outage, according to Apica spokesperson, Apple and other ecommerce sites were likely spared for an easy reason: They have designed their sites to spread themselves across multiple cloud vendors, so if a problem crops up in one cloud service, it doesn’t hurt them. This is, naturally, the recommended way to use a cloud service.

    Apple, Walmart, Newegg, Best Buy, Costco and, surprisingly, Amazon/Zappos were not affected by the outage.

    Organizations have since started looking for different means to avoid data loss and downtime and to better support different applications, not to mention resilient application support, customer management and data analytics. This is where multi-cloud computing can help solve the challenges and which focuses provisioning, managing and monitoring workload across many clouds.

    Multi-Cloud Computing

    Multi-cloud computing is termed as the use of more than one cloud environment, all of the same type or a mix of types, to satisfy business requirements. An enterprise can choose which workloads can be moved to different clouds, depending upon the service offered by cloud vendors, matching the business need.

    This article discusses the need of multi cloud adoption, its benefits and challenges in managing multiple cloud environments and how multi-cloud orchestrators help solve the challenges.

    Market Trend

    According to research firm IDC, by 2020 more than 85 percent of enterprises will adapt to multi-cloud architectures encompassing a mix of public cloud services, private clouds, community clouds and hosted clouds, driving up the rate and pace of change in IT organizations.

    According to research firm MarketsandMarkets:

    Cloud Model 2016 2021
    The Multicloud management market $939.3 million $3.4 billion (compound annual growth rate of 29.6%,)
    The hybrid cloud market $25.28 billion $84.67 billion

     

    What is Driving Multi-Cloud Adoption?

    All workload and business requirement cannot be the same—this is one of the primary drivers of a multi-cloud reality.

    Unique Needs: You can run each workload where it performs best, for the lowest cost.

    Legacy Apps: You can avoid the pain of migrating legacy apps to a new platform.

    Desire to Diversify: You can avoid vendor lock-in and latency while creating redundancy.

    Benefits of Multi-Cloud Computing

    • Flexibility: Companies can deploy to public, private and hybrid clouds using a range of services.
    • Reduce the expenditure: Competitive prices and services from different cloud providers enable companies to achieve optimum cost expenditure.
    • Enhanced autonomy: Companies avoid keeping all their IT workloads in one cloud provider’s basket.
    • Customization and enhanced IT performance: Customization leverages the best-of-breed capabilities from multiple cloud vendors.
    • Migration: Containers and microservices-based applications can be migrated easily across clouds.
    • Hardware diversity: Relying on multiple locations and multiple providers significantly reduces the chances of impacting QoS.
    • Avoid data loss and downtime: Using more than one cloud services helps an organization avoid data loss and downtime attributed to a breakdown in any single component in hardware, software, storage or network.
    • Multiple Geo Availability: Companies can leverage cloud vendors’ data centers in multiple geographies, enabling to scale the business.

    Challenges of Managing Multi-Cloud Environment

    While there’s a lot of talk about moving things between clouds, the reality is it’s still fairly new. Though clouds have become smart enough to put an end to data lock-in, every vendor deployment comes with its own set of challenges, such as unique portals and processes that companies need to manage and can be put into three different categories.

    Technical challenges

    • API: No single model of integration or infrastructure automation can work, as each cloud provider will provide a different API to access different cloud services.
    • Behaviors: There are many differences in how clouds behave for common actions or under certain circumstances. For example, some clouds automatically provision storage upon launch of a server or instance, while others do not.
    • Resource sizes and types: Each cloud provider will offer different sizes and types of compute, storage and network resources; hence, the IT team must think about provisioning with optimum resource size and type needed for their workloads.
    • Operating system images: Each cloud provider will provide a unique set of operating system images, which makes it difficult to run the workload using the same image in other cloud.
    • Hypervisors: Each cloud provider leverages different, and sometimes proprietary, hypervisor options.
    • Application stacks: Some cloud providers may provide a selection of common, preconfigured application stacks (such as LAMP or Java or .NET).
    • Add-on services and features: Each cloud provider will offer extra add-on services and features above and beyond basic compute, network and storage resources. These may include load balancing, application servers, analysis tools or databases.
    • Security capabilities: The access control capabilities will vary across cloud providers, becoming more complex if different providers demand different password complexities or authentication measures.
    • Network Capabilities: Each cloud offers different ways to define subnets, security groups and network gateways, increasing difficulty in network planning.

    Operational Challenges

    • Testing: Deploying apps to multiple clouds requires platform-specific testing, which needs separate automate tests targeting multiple cloud platforms.
    • Tool diversity: DevOps tools have to keep pace with the rapid changes being made to the platforms.
    • Maintaining security and governance: Companies will need to go through rules and regulations of each service provider to adhere to security compliance.
    • Managing applications and infrastructure configurations across multiple cloud stacks: This can be difficult since the cloud platforms do not share a common API, which exposes different service definitions and billing models.
    • Technical support and expertise: Extra administrative work and research is required to to determine the best provider and whether its services are compatible.
    • Geo-availability: Expand the business into new markets can be a challenge, as not all cloud providers have global footprints and offer data centers only in limited locations.

    Business Challenges

    • Cloud brokers: Managing cloud brokers is an additional cost while using multiple clouds.
    • Billing and Pricing: Each cloud provider offers unique pricing models as well as different billing capabilities, which necessitates the need for governance and cost optimization, providing summary along with detailed cost tracking across clouds.
    • Skill sets and training: A lack of skill set and expertise in different clouds in the organization can lead to outages of workloads and increase cost/effort.
    • Planning and execution: It can be difficult to choose the services that match a company’s business needs, pricing, governance and team’s expertise.

    How a Multi-Cloud Orchestrator Helps

    Regardless of the challenges, multi-cloud environments are growing, thanks in part to multi-cloud orchestration tools, which can prove to be a right fit to address above discussed challenges.

    These orchestration tools have the capability to make multiple cloud providers look like a single provider ensuring configuration of all cloud dependencies within one configuration model. These tools enable companies to automatically deploy and manage multi-cloud environments.

    Some of the big players in this segment are RightScale, OneOps, Cloudify and IBM Cloud orchestrator, which provide a standard set of interfaces and capabilities across a multi-cloud environment.

    We have identified some parameters which current multi-cloud management platforms are well-equipped to handle:

    • Planning and Execution of an application from design to transition to deployment.
    • Installation & configuration of infrastructure packages & services in an automated way.
    • Provisioning of application environment.
    • Deployment plan and execution.
    • Cost Management: Suggestion of cost effective cloud services and single dashboard to track the cost associated with different cloud services.
    • Monitoring of entire application stack.
    • Security & Governance as to who can view, create, execute environment related activities.
    • Blue-print Templates which can be easily reused to create a new environment.
    • Reporting: View a report of instances that are consumed by your organization across multiple clouds.

    Conclusion

    Multi-cloud orchestrator tools help address some of the above  challenges to configure, provision and deploy several cloud environments, as well as integrate service management from a single, self-service interface.

    Though present multi-cloud orchestration tools offer a more time- and cost-effective solution to manage different cloud providers for organizations to focus on larger business objectives, virtually all products in this category are young—bugs and inconsistencies can and will occur. Additionally, security can be a concern for many of the popular orchestration tools. Many APIs offered are not securely encrypted by default and need to have SSL added separately.

    We can say there is still a huge scope of improvement for multi-cloud orchestration tools to build more secure, easy-to-set up standardized workflows across different cloud providers to cover the challenges which multi-cloud computing era offers.

    About the Author / Rashi Sharma

    Rashi Sharma an architect working with Technology Office in HCL Technologies. She has expertise in AWS, DevOps consulting & configuration management methodologies. She is associated with DevOps COE, working on design and Development of DevOps solutions.

  • Micro Focus Unfurls Functional Testing Service

    Micro Focus Unfurls Functional Testing Service

    The merging of software assets from Micro Focus and Hewlett-Packard Enterprise (HPE) that occurred earlier this year included StormRunner, a series of load- and performance-testing tools. Micro Focus recently extended that portfolio with the introduction of Micro Focus StormRunner Functional, a suite of functional testing tools delivered as service that can be employed to test applications running on any browser, operating system or mobile device.

    Shane Evans, director of product management for application delivery management for Micro Focus, says StormRunner Functional spans a variety of automated tests addressing unified functional testing (UFT), UFT Pro and Selenium browser testing tools that include elements developed by both HPE and Micro Focus. The Micro Focus StormRunner Functional Testing service also includes pre-built integration with Google Analytics, Micro Focus Octane, GIT and Jenkins to streamline the testing process.

    Interest in automated testing has increased substantially in the last few years, says Evans, because developers are under more pressure than ever to roll out new applications and associated updates faster. Unfortunately, most developers don’t have the time required to test applications themselves, or there is simply not enough money in the budget to hire quality assurance teams to test every element of an application. Micro Focus StromRunnner Functional provides an alternative approach using a set of testing tools that have been widely employed across the enterprise for decades, says Evans.

    Evans notes Micro Focus is pursuing a comprehensive approach to application delivery management spanning everything from testing tools to application lifecycle management. Micro Focus is making the contention that most DevOps teams are a lot more interested in getting access to the results of a test than managing the actual testing technologies themselves, says Evans. In addition, advanced analytics and machine learning algorithms, which now are standard elements of testing process, require access to massive amounts of data to be effective. That data is a lot easier to aggregate in the cloud using SaaS applications than in an on-premises environment. In fact, Evans says, those requirements are among the factors driving a wave of recent acquisition across the application testing sector.

    Arguably, the biggest testing challenge organizations now face is moving away from processes based on IT Information Library (ITIL) guidelines to a more DevOps-centric process, under which continuous testing is more embedded within the application development process, Evans says. Functional testing is only one element of the testing process, but it has become more critical as end users become less forgiving of substandard digital experiences inside and out of enterprise IT environments. Regardless of who inside the organization is responsible for testing applications, the expectation now is that every application experience inside the enterprise will be on par with a consumer application experience.

    — Mike Vizard