[Learn more about creating and managing networks in our docs]
The story of the Stax product roadmap has always been one of trying to fill a 50-litre drum with 100-litres worth of priorities. There is so much involved in building a product that helps a wide variety of companies with their cloud ecosystem. Cloud is big!
From the beginning, we knew we had to build a solution for account management, authentication & authorization. These are fundamental aspects to working in an AWS context. Another aspect is networking, and it’s been on the roadmap from the start. But it was a big “missing” piece of the platform, and something we wanted to ensure got the appropriate focus.
We wanted to provide an opinionated, out-of-the-box way of doing this, a method that will work in 90% of cases. No two businesses have the same network topology or equipment, so it’s about taking out the initial guess work and head scratching whilst providing a level of flexibility.
We were aiming at producing a solution for those at the midmarket and emerging enterprise level, whose needs are at a certain level of complexity. This means customers can enjoy the benefits of networking without having to spend months “reading the manual” before realizing that, “oh crap, it doesn’t work the way we hoped.”
It was only recently, after getting those foundational aspects of Stax completed, that we turned our attention back to the big whiteboard, where the word ‘networking’ was written, circled, underlined, with big arrows pointing to it. Followed by a few exclamation marks.
Research and Development
Everyone wants to solve the networking challenge in a different way, so we decided the goal for Stax was the most flexible, highly-abstracted solution possible whilst paying homage to a bit more of the traditionalist view of a network with pipes and connections.
We surveyed our partners at Versent to learn of networking issues they have gone through during their cloud transformation projects. While every integration is different, there was a broad consensus. Everyone wanted a secure method for networking, along with connectivity for on-prem resources. That helped to inform the architecture and design we chose, as we learned from them what they needed to make their jobs easier. So we got to work!
Our Networking Design
The focus was on migration audiences as opposed to those using cloud-native, serverless approaches. We’re explicitly focusing on something for customers who want to bring their existing resources into the cloud. This is opposed to a Zero Trust Networking model, where systems within an organization operate through a broker, rather than communicating with each other directly.
We’re using the current AWS recommended pattern for networks. We initially wanted to build an “everything connects to everything” solution. But, inspired by a serverless network transit orchestrator proof-of-concept presentation at Re:invent 2019, we moved to a model whereby a customer can be more specific in their routing.
The model involves the creation of Networking Hubs. These consist of a Transit Gateway, a VPC that provides secure egress via a NAT Gateway, and a Route53 Hosted Zone to provide DNS. With this in place, customers can begin creating their Stax VPCs, each of which is allocated a unique CIDR range. Customers can centralize network gateway and VPC endpoints, and share across the organization, which is more cost-effective.
In line with our priorities, this is a flexible solution and one that is a bit more familiar to those new to the cloud. Customers don’t have to conform to our approach to networking. Whatever their networking approach, this will fit into the topology and workflow. At the outset we recognize that some customers might need a slightly more tailored ingress and egress for their cloud applications, so we have ensured that these can be toggled. Use the native AWS defaults, or switch them off and plug in your own appliance as required. Initial feedback from our partners suggests this approach is correct and fits with their needs.
What's Next?
The next stage of the Networks service will be focused on simplifying Direct Connect and VPN transit into the network. Customers can implement this themselves right now, but we’re focused on making it more straightforward for our users. We’re also making it easier for customers to customize their networking to suit their particular needs, with features like DNS endpoints– the first step to name resolution. Now we have the first version of the feature out, the roadmap is once again full of ideas, we’re looking forward to getting stuck in.
Topics
