3 ms·

I’m curious what you’re working with that is significantly different from one CSP to the next. I put most of my effort into AWS, but when I get staffed on a Goo

I’m curious what you’re working with that is significantly different from one CSP to the next. I put most of my effort into AWS, but when I get staffed on a Google Cloud project, there isn’t much that I can’t figure out pretty quickly, especially with IaC managing everything. As long as the CSP has good docs, I find it relatively easy to move from one to the next. There are certainly some cases where that breaks down, but it’s usually in specialized areas that I’d have to do some upskilling on in my preferred cloud anyway. The benefit of the cloud is its service and resource (i.e. building block) oriented nature. There’s a level of transparency to cloud-based services that just didn’t really exist before.

scarface_74 3y ago
> I’m curious what you’re working with that is significantly different from one CSP to the next. I work here: https://aws.amazon.com/professional-services/ https://aws.amazon.com/professional-services/ There is a lot more to any of the cloud providers than just VMs and networking. I haven’t done anything hardly with a raw EC2 instance in 5 years except for one or two deployment pipelines. AWS alone has 130 services. True many of them are hosted versions of open source products I work with call centers (Connect), Athena (Apache Presto), Step functions, and I have done some IOT work and of course Lambda and a lot more. I don’t do anything with traditional VMs. My specialty is “application modernization” meaning my work is a combination of DevOps and traditional application development using AWS services. There are all kinds of specialties within any of the major cloud providers.
- mschuster91 3y ago
  > I work with call centers (Connect), Athena (Apache Presto), Step functions, and I have done some IOT work and of course Lambda and a lot more. Well, Lambda has a multitude of competitors (although to my knowledge they are only competing on the principle of serverless computing, so you'll still have to re-write scripts using these), and same for IoT integration. The rest I'd say is pretty exotic stuff... and thanks for mentioning AWS Connect, that looks like something I'll have a deeper look into - do I get it correct that this is something like a combination of JIRA Service Desk/OTRS, some form of SIP telephony service plus a webchat and AI assistant?
  - scarface_74 3y ago
    It was originally the call center software that Amazon Retail used. It was ported to become an AWS service. For text to speech it uses Lex - the AWS version of Alexa. For other integrations you have it call a Lambda. It’s the standard type of software you use when calling into a call center with a mixture of automated help and operators. Like I said above, if you know your specialty well, it’s not hard to map your expertise to AWS services. It took me two years from never opening the AWS console but having literally decades of software development/architecture experience to working at AWS in consulting. I worked at a 60 person startup before. I’m more challenging the notion that all any of the cloud providers offer is a bunch of VMs and the surrounding networking infrastructure.
    - mschuster91 3y ago
      > I’m more challenging the notion that all any of the cloud providers offer is a bunch of VMs and the surrounding networking infrastructure. Granted, I'm biased because I work at a development-focused shop so my experience is the development/infra side of AWS and Azure as well as a healthy load of legacy on-prem servers (I leave my fingers off of GCP though, heard too many horror stories). We follow KISS - so just from a quick grep through our Terraform files it's almost all EC2, S3, Cloudfront, ELB, ACM, RDS, EFS, Beanstalk, ECS and EKS plus Cloudwatch for logging/monitoring, well wrapped in modules. That's stuff one can find pretty much everywhere, especially as most of our workloads are shifting to EKS. The things you use are IMHO more targeted for specialist use cases, and I can clearly see the value-add... I'd pay good money to never have to see JIRA again in my life.

scarface_74 3y ago

> I’m curious what you’re working with that is significantly different from one CSP to the next. I work here: https://aws.amazon.com/professional-services/ https://aws.amazon.com/professional-services/ There is a lot more to any of the cloud providers than just VMs and networking. I haven’t done anything hardly with a raw EC2 instance in 5 years except for one or two deployment pipelines. AWS alone has 130 services. True many of them are hosted versions of open source products I work with call centers (Connect), Athena (Apache Presto), Step functions, and I have done some IOT work and of course Lambda and a lot more. I don’t do anything with traditional VMs. My specialty is “application modernization” meaning my work is a combination of DevOps and traditional application development using AWS services. There are all kinds of specialties within any of the major cloud providers.

mschuster91 3y ago
> I work with call centers (Connect), Athena (Apache Presto), Step functions, and I have done some IOT work and of course Lambda and a lot more. Well, Lambda has a multitude of competitors (although to my knowledge they are only competing on the principle of serverless computing, so you'll still have to re-write scripts using these), and same for IoT integration. The rest I'd say is pretty exotic stuff... and thanks for mentioning AWS Connect, that looks like something I'll have a deeper look into - do I get it correct that this is something like a combination of JIRA Service Desk/OTRS, some form of SIP telephony service plus a webchat and AI assistant?
- scarface_74 3y ago
  It was originally the call center software that Amazon Retail used. It was ported to become an AWS service. For text to speech it uses Lex - the AWS version of Alexa. For other integrations you have it call a Lambda. It’s the standard type of software you use when calling into a call center with a mixture of automated help and operators. Like I said above, if you know your specialty well, it’s not hard to map your expertise to AWS services. It took me two years from never opening the AWS console but having literally decades of software development/architecture experience to working at AWS in consulting. I worked at a 60 person startup before. I’m more challenging the notion that all any of the cloud providers offer is a bunch of VMs and the surrounding networking infrastructure.
  - mschuster91 3y ago
    > I’m more challenging the notion that all any of the cloud providers offer is a bunch of VMs and the surrounding networking infrastructure. Granted, I'm biased because I work at a development-focused shop so my experience is the development/infra side of AWS and Azure as well as a healthy load of legacy on-prem servers (I leave my fingers off of GCP though, heard too many horror stories). We follow KISS - so just from a quick grep through our Terraform files it's almost all EC2, S3, Cloudfront, ELB, ACM, RDS, EFS, Beanstalk, ECS and EKS plus Cloudwatch for logging/monitoring, well wrapped in modules. That's stuff one can find pretty much everywhere, especially as most of our workloads are shifting to EKS. The things you use are IMHO more targeted for specialist use cases, and I can clearly see the value-add... I'd pay good money to never have to see JIRA again in my life.