What qualifies for Red Hat Developer Subscription for Teams?

The Red Hat Developer Subscription for Teams gives organizations already running other Red Hat technologies access to Red Hat Enterprise Linux for their development activities at no cost. It is available through a Red Hat representative or partner.

For organizations that don't have a dedicated Red Hat representative, Red Hat Enterprise Linux for Business Developers delivers a complete set of Red Hat Enterprise Linux software for development and test use cases in business environments at no cost. It's available via self-service at developers.redhat.com.

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 qualify as development use?

Figure 1 calls out the delimitation between development and production activities, as defined in 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 exploring how the Developer Subscription for Teams enables rapid development, testing, and deployment. Now we'll walk through each phase, as illustrated in Figure 1.

Software design and coding

When developing, updating, or maintaining a tax application, a design phase often outlines the intended end state, including functionality, architecture, features, and components. Once the design is accepted, the actual work of writing the code begins. The Developer Subscription for Teams covers the systems used to design new applications, upgrade existing ones with new features, overhaul legacy code, squash bugs, and so on.

Building

Once the code for our tax application is written, we might need to build the application by pulling in dependencies, setting appropriate values, and outputting the result 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 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. This allows for more thorough and targeted component testing.

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

Second, our middle tier can undergo a load test to demonstrate expected response times and validate that multiple calculations can be run simultaneously without causing 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 validating their integration is crucial.

First, we can spin up the other applications and ensure they're communicating with each other, then,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. We 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 their impact on our business and clearly document any steps teams must take 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 like 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 cover the automation piece of the push-to-production story, and production. Red Hat Enterprise Linux subscriptions cover the systems running our code repository and CI/CD pipelines because our production code flows 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 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 include 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, also fall into this category and use 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

Red Hat Developer subscriptions are 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.

For access to Red Hat Enterprise Linux for Business Developers, simply visit developers.redhat.com and register.