A Conversation with Cloud Practitioners on AWS and Multi Cloud
In this series of conversations, we talk with the cloud architects and practitioners, learn from them the journey and insights of working on the cloud platform.
I recently caught up with Michael Colbaugh and John Jones, networking and infrastructure engineers at a large software company that provides services as divergent as customer engagement and cyber intelligence. Michael and John both worked in the datacenter prior to the cloud adoption.
Sherry: Tell us what you do, are you on the IT side or product side?
Mike & John: We have always been on the product side, we run infrastructure for one of the biggest products we offer. Our company made decision to move to AWS, and we jumped right in. The product is quite complex with years of development and deployment in datacenter. We had no time to re-develop or re-factor before it was launched on AWS.
Sherry: What did you discover?
Mike & John: For a networking engineers coming from datacenter world where there is industry standard and far more richer features, AWS networking services are limited. Things we take for granted such as NAT function in VPN service does not exist in AWS. You don’t know that until you need it, and the documentation tends not to discuss the limitation.
Sherry: In some cases AWS does document its limitation — but you need to know the limitation to find it, that is, you know the limitation, do google search, then you find the documentation that confirms it. Not always though.
Why do you need to deal with these limitations?
Mike & John: It all depends on use cases. In our situation, we have a more complex use case where we need to connect to partners or customers that we have no control of the subnets their systems operate in. Address conflict between two organizations are common, so we have to solve for it ourselves as AWS native function does not.
Sherry: What else surprised you?
Mike & John: We have had AWS EC2 instances randomly die, that is a pain.
If a product were designed and developed with AWS specifics in mind, it could be made cost effective by leveraging the AWS native services. But the reality is that hardly any app is designed like that. In addition, if you would like a product to stay generic so that it could be moved to a different cloud, then you can’t really develop a cloud specific product. In that case you could spend a lot of effort trying to do the same thing you were doing in the datacenter.
Sherry: Do you have a different cloud in mind?
Mike & John: Yes. We have clients who wants our service to be deployed on Azure.
Sherry: Is this industry specific?
Mike & John: It tends to be that way. Certain industry wants to consume cloud services in Azure. That is not surprising.
Sherry: How did Aviatrix help?
Mike & John: Aviatrix simplifies networking, so we don’t have to deal with the nuances of AWS networking.
We have multiple products and multiple groups. There are multiple use cases where Aviatrix helps solving: Transit Network, Egress Filter and Site2Cloud. Aviatrix fills in the missing functions in AWS native networking services.
For example we recently purchased a product that requires Internet access. As infrastructure engineer, it’s our responsibility to ensure egress control is enforced.
Sherry: What’s the next step?
Mike & John: We’ll be soon ready to look at monitoring and visibility and integrate Aviatrix logging and alert output into our NOC system.
Sherry: Let us know if you need help in reviewing your design to make sure you monitor the right metrics. Thank you so much for talking with us!
