Less Time Learning, More Time Building

Back in 2018, I decided to use my free time to help modernize a family member’s business. Along the way, I wanted to gain some experience and understanding of AWS.

Ultimately, I discovered that nearly all my free time was spent learning AWS cloud infrastructure concepts. I had only a small fraction of my time left to focus on building the modern, cloud-based solution that I originally had in mind. As I planned more feature requests for the app, I realized that I needed a better approach.

In early 2020, I discovered Heroku. Since I didn’t need to worry about underlying cloud configurations, I could focus my time on adding new features. 

The Heroku ecosystem worked out great for my simple use case, but I began to wonder about more complex use cases. What about the scenario where a collection of secure and private services needs to interact with one another for a payment processing solution?

Would this use case force me to live in the ecosystem of one of the big three cloud service providers? I’m going to find out.

The Current State of Secure Microservices

For several years, I was fortunate to work in an environment that valued the DevOps lifecycle. The DevOps team handled all things cloud for me, so I could focus on architecting and building microservices to meet my customers’ needs. 

During that time of my life, this environment was the exception, not the norm. I just did a search for “companies lacking cloud infrastructure knowledge” in my browser, and the results yielded some pretty surprising conclusions:

• There is a serious shortage of cloud expertise.
• The lack of cloud skills is leading to significant performance impacts with cloud-native services.
• Cloud security is a challenge for 1 in 4 companies.

The top search results talked about a lack of understanding of the core cloud concepts and the need for crucial training for teams to be effective. The training most teams need usually falls by the wayside as customer demands and deliverables take higher priority.

With this current approach, most cloud implementations are forced to move at a slower pace, and they’re often exposed to unknown vulnerabilities.

The current state of securing your microservices in the cloud is not a happy one.

The Ideal State for Secure Microservices

The ideal state for cloud-native solutions would adhere to a personal mission statement I established several years ago:

“Focus your time on delivering features/functionality that extends the value of your intellectual property. Leverage frameworks, products, and services for everything else.”

    – J. Vester

In this context, those with a directive to drive toward cloud-native solutions should be able to move at a pace that aligns with corporate objectives. They shouldn’t be slowed by the learning curve associated with underlying cloud infrastructure.

So, what does this look like when we’re facing a cloud solution encompassing multiple microservices, all of which need to be isolated from the public and adhere to compliance regulations (like SOC, ISO, PCI, or HIPAA)?

About Private Spaces

My 2020 Heroku experience was positive. So I wanted to see how it would work with this complex use case. That’s when I discovered Private Spaces.

Private Spaces are available as a part of Heroku Enterprise. They’re dedicated environments for running microservices within an isolated network. This approach allows teams to deploy their services into a network that’s not exposed to the public internet. Under the hood, these services function exactly the same as in my basic use case. I can set them up through the Heroku CLI, and simple Git-based commands can trigger deployments.

For the regulatory compliance needs, I can lean on Heroku Shield to help me comply with PCI DSS, HIPAA, ISO (27001, 27017, and 27018), and SOC (1, 2, and 3). 

At a high level, Heroku lets me implement a secure cloud-native design that can be illustrated like this:

Here, we have an implementation that leverages Heroku Shield all within a Private Space. This allows a collection of microservices — utilizing several different programming languages — to interact with all the major primary and secondary card networks, all while adhering to various regulatory compliance requirements. Additionally, I get secure communications with the Salesforce platform and GitLab.

Heroku in Action

Using the Heroku CLI, I can get my Private Space and Heroku Shield up and running. In Heroku, this is called a Shield Private Space. Here are some high-level examples to work through the process.

To create a new Shield Private Space, we use spaces:create and add the --shield option.

$ heroku spaces:create payment-network --shield --team payments-team --region oregon
Creating space payment-network in team payments-team... done
=== payment-network
Team: payments-team
Region: oregon
State:  allocating

If the use case requires Classless Inter-Domain Routing (CIDR) ranges, I can use --cidr and --data-cidr flags.

You’ll notice that I created my Private Space in the oregon region. You can create a Private Space in one of 10 available regions (in the U.S., Europe, Asia, and Australia). For a list of available regions, do the following:

$ heroku regions
 ID Location Runtime 
 ───────── ─────────────────────── ────────────── 
 eu Europe Common Runtime 
 us United States Common Runtime 
 dublin Dublin, Ireland Private Spaces 
 frankfurt Frankfurt, Germany Private Spaces 
 london London, United Kingdom Private Spaces 
 montreal Montreal, Canada Private Spaces 
 mumbai Mumbai, India Private Spaces 
 oregon Oregon, United States Private Spaces 
 singapore Singapore Private Spaces 
 sydney Sydney, Australia Private Spaces 
 tokyo Tokyo, Japan Private Spaces 
 virginia  Virginia, United States Private Spaces

For each microservice that needs to run in the payment-network Private Space, I simply add the --space option when running the apps:create command:

$ heroku apps:create clearing-service --space payment-network
Creating app... done, clearing-service

To grant consumers access to the payment-network space, I can maintain the allowed list of trusted IPs:

$ heroku trusted-ips:add 192.0.2.128/26 --space payment-network
Added 192.0.2.128/26 to trusted IP ranges on payment-network
 -    WARNING: It may take a few moments for the changes to take effect.

Conclusion

Teams are often given a directive from above to adopt a cloud-native approach. However, many teams have a serious gap in understanding when it comes to deploying secure cloud architectures. If you’re using one of the big three cloud providers, then bridging this gap will come at a price—likely missed timelines expected by the product owner.

Is there a better option for secure cloud deployment? I think Private Spaces combined with Heroku Shield represents a better option. For me personally, it also matters that Heroku is part of the solutions platform from Salesforce, which has a history of dedication to providing a cloud adoption alternative focused on the success of its customers. So I felt like this was a long-term strategy for consideration.

Have a really great day!