Today I want to talk about Ansible Service Broker and Ansible Playbook Bundle. These components are relatively new in the Red Hat OpenShift ecosystem, but they are now fully supported features available in the Service Catalog component of OpenShift 3.9.
Before getting deep into the technology, I want to give you some basic information (quoted below from the product documentation) about all the components and their features:
- Ansible Service Broker is an implementation of the Open Service Broker API that manages applications defined in Ansible Playbook Bundles.
- Ansible Playbook Bundles (APB) are a method of defining applications via a collection of Ansible Playbooks built into a container with an Ansible runtime with the playbooks corresponding to a type of request specified in the Open Service Broker API specification.
- Playbooks are Ansible’s configuration, deployment, and orchestration language. They can describe a policy you want your remote systems to enforce, or a set of steps in a general IT process.
Continue reading “Customizing an OpenShift Ansible Playbook Bundle”
Without proper testing, we should not ship any container. We should guarantee that a given service in a container works properly. Meta Test Family (MTF) was designed for this very purpose.
Containers can be tested as “standalone” containers and as “orchestrated” containers. Let’s look at how to test containers with the Red Hat OpenShift environment. This article describes how to do that and what actions are needed.
MTF is a minimalistic library built on the existing Avocado and behave testing frameworks, assisting developers in quickly enabling test automation and requirements. MTF adds basic support and abstraction for testing various module artifact types: RPM-based, Docker images, and more. For detailed information about the framework and how to use it check out the MTF documentation.
Continue reading “Container Testing in OpenShift with Meta Test Family”
Christian Posta, Chief Architect at Red Hat, presented the story of a fictitious company1 moving a monolithic application to microservices.
When considering risk, we think we know the bad things that can happen and the probabilities of those bad things actually happening. Christian defines a monolith as a large application developed over many years by different teams that delivers proven business value while being very difficult to update and maintain. Its architecture, elegant at one point, has eroded over time. That makes it difficult to assess the risk of migrating a monolith.
Continue reading “Red Hat Summit: Lowering the risk of monolith to microservices”
Red Hat Senior Architects Marius Bogoevici and Christian Posta recently presented an overview of event-driven architecture, taking the audience from the basics of enterprise integration to microservices and serverless computing. Standing in front of a packed room at Red Hat Summit, their talk addressed four basic points:
- Event-driven architectures have been around for a while. What are they, why are they powerful, and why are back en vogue?
- Messaging is often used as a backbone for event-based distributed systems. What options do we have for cloud-native event-driven architectures?
- Integration is necessary for any organization. How do streaming, cloud-native architectures, and microservices fit in?
- Are Functions-as-a-Service (FaaS) the next utopian architecture? Where do functions fit in a world of microservices?
The entire session was done with three enterprise concerns in mind. First is the divide between agile systems and purpose-built systems. While the purpose-built system is optimized for a small set of use cases, it is very difficult to change if new use cases arise or the old use cases become irrelevant. We have to be agile to adapt to a constantly changing environment. Another concern is resource utilization. We want to eliminate waste and get the most out of our systems and resources, although the cloud in general and containers in particular make more distributed architectures practical. Finally, Christian made the observation that we cannot build complex systems from complex parts. The components we develop must be as simple and understandable as possible.
Continue reading “Red Hat Summit: An Eventful Tour from Enterprise Integration to Serverless”
Join us for the next online DevNation Live on May 17th at 12pm EDT for Serverless and Servicefull Applications: Where Microservices Complements Serverless hosted by Burr Sutter. Serverless is a misnomer. Your future cloud-native applications will consist of both microservices and functions, wrapped in Linux containers, but in many cases where you, the developer, will be able to ignore the operational aspects of managing the infrastructure and even much of the runtime stack.
In this technical session, we will start by using Apache Whisk, a Functions-as-a-Service (FaaS) engine, deployed on Kubernetes and Red Hat OpenShift to explore how you can complement cloud-native Java applications (microservices) with serverless functions. Next, we’ll open up a serverless web application architecture and deploy an API Gateway into the FaaS platform to examine the microservices talking to the serverless functions. We finish with a look at how event sinks and event sources map in the serverless world.
Register now and join the live presentation at 12pm EDT, Thursday, May 17th.
Continue reading “Next DevNation Live: Serverless and Servicefull Applications: Where Microservices Complements Serverless, May 17th, 12pm EDT”
Serverless computing (often called Functions-as-a-Service, or FaaS) is one of the hottest emerging technologies today. The OpenWhisk project, currently in incubation at Apache, is an open-source implementation of FaaS that lets you create functions that are invoked in response to events. Our own Brendan McAdams gave a presentation and demo that explained the basics of serverless, how the OpenWhisk project works, and how to run OpenWhisk in OpenShift.
Brendan outlined the three properties of a serverless / FaaS platform:
- It responds to events by invoking functions
- Functions are loaded and executed on demand
- Functions can be chained together with triggered events from outside the FaaS platform itself.
Continue reading “Red Hat Summit: Functions as a Service with OpenWhisk and OpenShift”
Have you ever thought to yourself, “Today’s world would be so much richer if we had 29 kinds of hummus?” Neither has Stephanos Bacon, Senior Director of Portfolio Strategy for Red Hat Application Platforms. His entertaining presentation moved from the options available to humans hungry for hummus to a discussion of the bewildering array of choices available to developers and architects. Although too many choices can be a bad thing1, it’s important to understand what choices are relevant today and that the relevance of those choices is always shifting.
There are several things that don’t change, however. Some of the concerns that have been with us since before the dawn of time2 include:
- Making developers as productive as possible
- Balancing productivity with governance and compliance
- Delivering software predictably and in a timely manner
- Making software as robust as possible
- Prioritizing usability and accessibility
But beyond these goals, there are three factors that are always in flux:
Continue reading “Red Hat Summit: Clouds today, serverless tomorrow”
You’re in an IT department. How does the rest of the organization see you? As a valuable asset whose code and APIs make a difference in the marketplace, or as a necessary evil that should be trimmed as much as possible? Containers, microservices, and serverless computing can make you more responsive, flexible, and competitive, which in turn makes your organization more effective. And that puts you solidly in the asset column.
After sprinting through the streets of San Francisco from the stage of the opening keynote at Red Hat Summit 2018 (replay available here), Burr Sutter hosted a packed house in Moscone South to talk about these technologies. Containers are widely accepted (see the announcement from Red Hat and Microsoft for an example), microservices are increasingly popular as an approach to modernizing monolithic applications, and serverless computing is emerging as an important new programming model.
Continue reading “Red Hat Summit: Containers, Microservices, and Serverless Computing”
[Cross posted from the OpenShift blog]
About a year ago Red Hat announced its participation as a launch partner of the Istio project, a service mesh technology that creates an application focused network that transparently protects the applications from abnormalities in environments. The main goals of Istio are enhancing overall application security and availability through many different capabilities such as intelligent routing, circuit breaking, mutual TLS, rating, and limiting among others. Ultimately Istio is about helping organizations develop and deploy resilient, secure applications and services using advanced design and deployment patterns that are baked into the platform.
As part of our investments in making the technology easily consumable to Kubernetes and OpenShift users, Red Hat has created a ton of content:
- learn.openshift.com: A web-based OpenShift and Kubernetes learning environment where users get to interact through the web browser with a real running instance of OpenShift and Istio service mesh with zero install time and no sign-up required.
- Istio tutorial: Want to try the web-based scenario yourself from scratch? This Git repo contains instructions on how to set up an environment for yourself.
- Introducing Istio Service Mesh for Microservices book by Christian Posta and Burr Sutter
- Blog posts on the OpenShift and Red Hat Developer blogs
Continue reading “Getting Started with Istio and Jaeger on Your Laptop”