APIs continue to spread, as seen in this 2019 report from ProgrammableWeb, which shows a 30% increase over last year’s growth rate. More regulations are enforcing the use of APIs to open up companies and foster innovation. Think of the Payment Services Directive version two (PSD2), open banking, and the public sector releasing 0pen data APIs. With such an abundance of APIs, it becomes increasingly crucial to get the value out of your APIs and differentiate yourself from the growing competition. It’s time to design and manage your APIs as a Product.
Change your organization
Designing an API as a Product implies a lot of changes in the way APIs are designed and managed. It means changing your mindset from “packaging existing services” to “fulfilling customer needs.” For teams in charge of an API, this mindset implies being in charge of a product instead, and thus:
- Focusing on customer needs rather than existing assets.
- Managing APIs continuously rather than for a project’s lifetime.
- Moving from finite resources to elastic computing.
- Evolving from a central team specialized in APIs to product cross-functional teams with a variety of competencies.
In a nutshell, designing an API as a Product means:
- Conceiving it specifically to solve a customer problem.
- Setting shared indicators of the value delivered by the API.
- Having a feedback loop to know what to improve.
Change your design process
Designing APIs as a Product also means changing the way we craft APIs (by adopting API design thinking):
- The first step of design thinking applied to APIs is focusing on the customers. Through their eyes, what is their pain? Empathize means meeting with and listening to your potential new customers. You will discover their understanding, how they are organized, which technical ecosystem they use, etc.
- Then, you would synthesize your findings to define which problem they are trying to solve and identify the Job to be Done. Customers wanting to perform a transaction to buy a pet and customers willing to synchronize their pet inventory would lead to two very different Petstore APIs.
- Once defined, you can foster new ideas through a process known as API Ideation. During this step, you knock up different API designs to see if one stands up as a plausible solution.
- During the API Prototyping phase, you mock your API based on meaningful examples to end up with a working API. Other team members can give their feedback on your design attempt.
- The penultimate step is to get feedback on your final design from your early adopters and thus refine the business expectations for your API.
- Finally, you implement the actual API.
Open source communities to help you design APIs as a Product
So far, we have only spoken about organizational changes. Dedicated tools and open source communities can help you succeed in designing and managing APIs as a Product:
- Microcks is the open source Kubernetes-native tool for API mocking and testing that helps you during the Ideation and Prototyping phases.
- Apicurio helps you design better API contracts in a collaborative fashion. Architects, product owners, designers, and developers can work together on the API designs.
- Red Hat 3scale API Management eases the design and management of APIs as a Product by promoting the API designs, collecting feedback, and actually managing your APIs as a Product.
In the next article, we’ll look at how the most recent version of 3scale actually helps you build APIs as a Product.
Red Hat continues to increase the features available for users looking to implement a 100% open source, event-driven architecture (EDA) through running Apache Kafka on Red Hat OpenShift and Red Hat Enterprise Linux. The Red Hat Integration Q4 release provides new features and capabilities, including ones aimed at simplifying usage and deployment of the AMQ streams distribution of Apache Kafka.
Continue reading “Red Hat simplifies transition to open source Kafka with new service registry and HTTP bridge”
In this article, we’ll cover microservice security concepts by using protocols such as OpenID Connect with the support of Red Hat Single Sign-On and 3scale. Working with a microservice-based architecture, user identity, and access control in a distributed, in-depth form must be carefully designed. Here, the integration of these tools will be detailed, step-by-step, in a realistic view.
This article exemplifies the use of tools that can securely run your businesses, avoiding using homemade solutions, and protecting your services by using an API gateway, preventing your applications from being exposed to the public network. The use of an API gateway also provides additional access control, monetization, and analytics.
Continue reading “How to secure microservices with Red Hat Single Sign-On, Fuse, and 3scale”
A couple weeks ago I was faced with the challenge of installing Red Hat 3scale and configuring its tenants using solely the command line — no GUI allowed. This is a rather interesting use case, so I decided to write this article and show how to do it with just seven commands!
(By the way, I also decided to include Red Hat Single Sign-On (SSO) in the mix because I want my APIs to use OpenID Connect (OIDC) for authentication. But I’ll leave those commands to a future article.)
Continue reading “Install Red Hat 3scale and configure tenants with 7 simple commands”
In the previous article of this series, Deploy your API from a Jenkins Pipeline, we discovered how the 3scale toolbox can help you deploy your API from a Jenkins Pipeline on Red Hat OpenShift/Kubernetes. In this article, we will improve the pipeline from the previous article to make it more robust, less verbose, and also offer more features by using the 3scale toolbox Jenkins Shared Library.
Continue reading “Using the 3scale toolbox Jenkins Shared Library”
In a previous article, 5 principles for deploying your API from a CI/CD pipeline, we discovered the main steps required to deploy your API from a CI/CD pipeline and this can prove to be a tremendous amount of work. Hopefully, the latest release of Red Hat Integration greatly improved this situation by adding new capabilities to the 3scale CLI. In 3scale toolbox: Deploy an API from the CLI, we discovered how the 3scale toolbox strives to automate the delivery of APIs. In this article, we will discuss how the 3scale toolbox can help you deploy your API from a Jenkins pipeline on Red Hat OpenShift/Kubernetes.
Continue reading “Deploy your API from a Jenkins Pipeline”
Deploying your API from a CI/CD pipeline can be a tremendous amount of work. The latest release of Red Hat Integration greatly improved this situation by adding new capabilities to the 3scale CLI. The 3scale CLI is named 3scale toolbox and strives to help API administrators to operate their services as well as automate the delivery of their API through Continuous Delivery pipelines.
Having a standard CLI is a great advantage for our customers since they can use it in the CI/CD solution of their choice (Jenkins, GitLab CI, Ansible, Tekton, etc.). It is also a means for Red Hat to capture customer needs as much as possible and offer the same feature set to all our customers.
Continue reading “3scale toolbox: Deploy an API from the CLI”
With companies generating more and more revenue through their APIs, these APIs also have become even more critical. Quality and reliability are key goals sought by companies looking for large scale use of their APIs, and those goals are usually supported through well-crafted DevOps processes. Figures from the tech giants make us dizzy: Amazon is deploying code to production every 11.7 seconds, Netflix deploys thousands of time per day, and Fidelity saved $2.3 million per year with their new release framework. So, if you have APIs, you might want to deploy your API from a CI/CD pipeline.
Deploying your API from a CI/CD pipeline is a key activity of the “Full API Lifecycle Management.” Sitting between the “Implement” and “Secure” phases, the “Deploy” activity encompasses every process needed to bring the API from source code to the production environment. To be more specific, it covers Continuous Integration and Continuous Delivery.
Continue reading “5 principles for deploying your API from a CI/CD pipeline”
You have probably already heard about the service mesh concept and one of its leading implementations, Istio. In the 3scale engineering team at Red Hat, we are working on a component to extend the functionality of Istio (and Red Hat’s distribution, Maistra) by integrating some API Management features via the 3scale platform. In this article, I’ll describe this work and some of the decisions made along the way.
Continue reading “Looking up a hash table library for caching in the 3scale Istio adapter”
Red Hat Summit 2019 is rocking Boston, MA from May 7-9 in the Boston Convention and Exhibition Center. Everything you need to know about the current state of open source enterprise-ready software can be found at this event. From customers talking about their experiences leveraging open source in their solutions, to the creators of open source technologies you’re using, and all the way down to hands-on lab experiences on these technologies.
This hands-on appeal is what this series of articles is about. Previously, we looked at the labs in the Cloud-Native App Dev track, and this time, we provide a roadmap to the “Integration and APIs” lab content.
Continue reading “Red Hat Summit 2019 Labs: Integration and APIs roadmap”