What qualifies for Red Hat Developer Subscription for Teams?

Recently, Red Hat relaunched the Developer Subscription for Teams, enabling organizations already running other Red Hat technologies to access Red Hat Enterprise Linux for their development activities without friction. In this article, we clarify what Red Hat defines as development activities and highlight some exciting use cases for the Developer Subscription for Teams.

What activities are considered development use?

Figure 1 calls out the delimitation between development and production activities according to Appendix 1 of the Red Hat license agreement. To begin breaking this down, let’s start at the far left end, where systems would leverage the Developer Subscription for Teams.

An example application

Let’s consider a fairly simple yet mission-critical application: a tax calculator. When most businesses run transactions for goods and services, the appropriate taxes must be calculated and added to the total purchase price. Our example application consists of three parts:

• A database that stores the appropriate tax information and rates.
• A middle tier that retrieves tax information from the database and performs calculations.
• A front-end system running a RESTful API that’s used to interact with the application.

These three tiers come together to form our tax application. They will be the basis for considering how the Developer Subscription for Teams enables the rapid development, testing, and deployment of this application. Now we’ll walk through each phase, as illustrated in Figure 1.

Software design and coding

When developing, updating, or maintaining this tax application, there are often design phases meant to outline the intended end state: functionality, architecture, features, and components. Once the design is accepted, then the actual work of writing the code begins. The systems used for designing a new application or upgrading an existing one with new features, overhauling legacy code, squashing bugs, etc., would all be covered by the Developer Subscription for Teams.

Building

Once the code for our tax application is written, we might need to build the application, which means pulling in dependencies, setting appropriate values, and outputting them into a form that can easily be deployed. We might also need to build multiple deployment packages that can be deployed across multiple systems in multiple environments and compute spaces, such as a cloud provider or on-premise datacenter.

Since this action might require more computational power than what a standard workstation provides, it makes sense to leverage the capabilities of a hyperscaler. The systems we use to build the application would also qualify for the Developer Subscription for Teams.

Unit testing

Our three-tier tax application, composed of three parts (a database, a middle tier, and a front-end API), can be broken apart and tested individually, allowing for more thorough testing of the components and more targeted testing.

Our database can be loaded with the appropriate tax information and then put through a schema update test to ensure tax information can be updated without application downtime.

Second, our middle tier can be put through a load test to demonstrate expected response times and validate that multiple calculations can be run simultaneously without causing calculation collisions.

Finally, our front-end API’s role-based access control (RBAC) functionality can be tested to ensure only requests coming from the appropriate systems are accepted and sent to be processed by the application, and that the API returns the results in a data format that other applications can easily consume.

What’s unique about this specific step in the software development life cycle is that the number of systems needed to properly test and validate each unit of the application increases almost exponentially. A database system is necessary, and we also need a system to run some test transactions via a connection to the database while another system is running a schema update. Our middle-tier system needs multiple other systems connected and requesting taxes be calculated while being able to reference an external source of controlled data to ensure calculations are accurate. Finally, our API needs to be receiving requests from different sources, some of which are allowed via RBAC rules and some that are not, while being able to return consumable data to those authorized sources.

System integration and integration testing

At this step in the software development life cycle, we start to put the puzzle pieces of our application landscape together. Here, we’ll combine our example tax application with our existing point-of-sale application, our ledger application, our inventory tracking application, and so on. All these applications must work together successfully for our customers to be able to make a purchase, so testing and validation of the integration of these various applications is crucial.

First, we can spin up the other applications and ensure they’re communicating with each other; then, we can add in our example tax application. Once the appropriate API endpoints are specified, RBAC rules are written, and network communication is validated, we can test running real-world transactions through our system and look for any piece of the puzzle that isn’t working or is blocking a successful purchase. We can also use real-world data here to ensure our test environment completes the purchase as expected.

Pre-prod testing

Here, we develop, test, and practice the steps needed to safely introduce our new example tax application to our production environment in a space that closely resembles it. We’ll walk through identifying what outages are required and what impact that will have on our business, as well as clearly documenting any steps that need to be taken by teams to deploy our new tax application successfully. These steps can be tested multiple times for training and practice purposes in this environment without impacting production.

An environment such as this is often a scaled-down version of production that is constantly running, and has multiple teams that can access and leverage it for various activities. Again, the Developer Subscription for Teams covers this environment, removing the subscription barrier to entry and having an appropriate place to test the introduction of our tax application to production.

Push to production

Here’s where we cross the bridge from the Developer Subscription for Teams into “production” Red Hat Enterprise Linux subscriptions. Let’s say our organization uses a combination of continuous integration/continuous delivery (CI/CD) pipelines and Red Hat Ansible Automation Platform to deploy our applications in production from our code repository. The two are closely integrated to perform the steps we identified during testing in our pre-prod environment.

Our Red Hat Ansible Automation Platform subscriptions would cover the automation piece of the push-to-production story, and production. Red Hat Enterprise Linux subscriptions would cover the systems running our code repository and CI/CD pipelines, because our production code is flowing through them. Like the Developer Subscription for Teams, most production Red Hat Enterprise Linux subscriptions are cloud-eligible, meaning that these systems can run on-premise or off, and in the case of the CI/CD pipelines, can be spun up in a cloud on-demand to support our deployment activities.

Monitor

These systems are the watchers on the (proverbial) wall: constantly checking in on our various production and pre-production systems, ensuring they’re up and running as expected. Should a system go down or become unresponsive, these systems are responsible for identifying the downed system(s), attempting to recover services automatically, and, if that fails, reaching out for human intervention to restore functionality via various communication systems such as email or chat notifications. The systems watching for outages, attempting automatic recovery, and transporting outage notifications would consume production Red Hat Enterprise Linux subscriptions.

Update and maintain

The last block called out in Figure 1 encompasses systems used to keep our production environment running and healthy. These could be systems dedicated to storing updates for our systems (such as Red Hat Satellite) as well as systems used to apply these updates across our landscape (such as Red Hat Ansible Automation Platform). Other systems used to support these actions, such as bastion servers, proxies for downloading updates, and systems hosting firmware updates or other update packages, would also fall into this category, leveraging a production Red Hat Enterprise Linux subscription.

For a more condensed view of various systems and their respective subscription, here’s a quick reference table:

Conclusion

The Developer Subscription for Teams is a powerful option for software development and testing in an organization, allowing for easy consumption of Red Hat Enterprise Linux in the spirit of building and testing new and existing applications.

If you’re interested in the Developer Subscription for Teams, reach out to a Red Hatter today.