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 allow 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. But 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 that 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 their customers. So I felt like this was a long-term strategy for consideration. Have a really great day! 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. 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. Heroku. 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? collection of secure and private services needs to interact with one another 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. DevOps 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. 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. lack of understanding crucial training 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 “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)? multiple microservices isolated from the public adhere to compliance regulations 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 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). compliance Heroku Shield 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. Shield Private Space To create a new Shield Private Space, we use spaces:create and add the --shield option. spaces:create --shield $ 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 $ 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. --cidr --data-cidr 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: regions $ 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 $ 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: payment-network --space apps:create $ heroku apps:create clearing-service --space payment-network
Creating app... done, clearing-service $ 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 allow list of trusted IPs: payment-network $ 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. $ 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. But 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 that 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 their customers. So I felt like this was a long-term strategy for consideration. Have a really great day!

This story contains AI-generated text. The author has used AI either for research, to generate outlines, or write the text itself. 

The is an opinion piece based on the author’s POV and does not necessarily reflect the views of HackerNoon.

Less Time Learning, More Time Building: A Quest for Secure Microservices

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

5 Signs You’ve Built a Secretly Bad Architecture (And How to Fix It)

When You Need More Power Than Lambda Provides

Why Being Likable At Work Matters

Windows Sticky Keys Exploit: The War Veteran That Never Dies

Is ‘bias for action’ making product managers lazier?

5 Signs You’ve Built a Secretly Bad Architecture (And How to Fix It)

When You Need More Power Than Lambda Provides

Why Being Likable At Work Matters

Windows Sticky Keys Exploit: The War Veteran That Never Dies

Is ‘bias for action’ making product managers lazier?

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps