Cloud services from a developers perspective

t4keheart

Weaksauce
Joined
Sep 24, 2019
Messages
111
Hi guys,
I would like to know from a developers perspective, what exactly are the benefits of utilizing cloud services? Which products and service offerings are most commonly used in the field of software engineering?

I wasn't exactly sure how to word this question- I understand what cloud computing is, I can read up on what each of the services do, but in a lot of ways it seems like buzz-word people like to throw around.
If you look on amazon AWS cloud services page, there's 50+ different offerings with different fancy names and a pretty vague description of what it actually does.
I'd like a better general understanding of which of these services (Amazon S3, Azure, etc.) are used most commonly in the real world when launching/deploying a new web app/phone app.

For instance, consider an established company who can afford the equipment to host everything in-house, why might they choose to utilize a cloud based offering instead?

Thank you!
 
Convenience, speed, cost.
I submit code, or update YAML in my repo. Do a PR, get it onto `main` branch. From there, automatically, CI/CD kicks in and pushes my changes out to where ever I needed them to go (Test, Pre-Prod, or Prod). I don't have to look at, think about, or "do" much of anything.
When I want to setup something new, again, it's dead simple and all done in code. No procurement of hardware, no real need to be held up by other teams (especially network, they always hold everything up) doing their configs and what not, and when I'm done, I can tear it down and the cost along with it is also gone.
I want a VM (yuck) with insert-random-other-crap here? Boom, it's all right there, you saw it all in the catalogs yourself. Want to use containers backed by K8s? Cool, it's right there and the best part is, you don't have to touch the hardware or even the K8s admin plane... you just create or update a helm chart and away you go.
Your lack of knowledge on what those services are is pretty irrelevant. If you know you need XYZ thing, you know that and you use it. Each of those offerings in the catalogs is there because of customer demand.

Just because a company could CapEx everything to run shiny-new-thing, doesn't mean they wouldn't rather OpEx it instead.
 
Convenience, speed, cost.
I submit code, or update YAML in my repo. Do a PR, get it onto `main` branch. From there, automatically, CI/CD kicks in and pushes my changes out to where ever I needed them to go (Test, Pre-Prod, or Prod). I don't have to look at, think about, or "do" much of anything.
When I want to setup something new, again, it's dead simple and all done in code. No procurement of hardware, no real need to be held up by other teams (especially network, they always hold everything up) doing their configs and what not, and when I'm done, I can tear it down and the cost along with it is also gone.
I want a VM (yuck) with insert-random-other-crap here? Boom, it's all right there, you saw it all in the catalogs yourself. Want to use containers backed by K8s? Cool, it's right there and the best part is, you don't have to touch the hardware or even the K8s admin plane... you just create or update a helm chart and away you go.
Your lack of knowledge on what those services are is pretty irrelevant. If you know you need XYZ thing, you know that and you use it. Each of those offerings in the catalogs is there because of customer demand.

Just because a company could CapEx everything to run shiny-new-thing, doesn't mean they wouldn't rather OpEx it instead.

cool- thanks for the response. For some context, I'm a self-taught coder (JS/TypeScript, Node/Express, Python, PHP, HTML/CSS, some C#) and do some development projects on the side (think gigs on sites like upwork). I've worked in IT for the past 12 years or so doing the network/sys admin thing, but I would like to eventually make the switch and get a job doing strictly development work.... thus I'd like a better understanding of how real dev teams operate in the wild with these services.

so, git/github, kubernetes, docker would be the main ones, then? Am I missing anything else you use often?

  1. How is CI/CD implemented? Are you referring to simply pushing/pulling to/from various repo's? Or is something more involved in this process?
  2. What platform do you use to build out vm's? What's the specific product called?
  3. I've used services such as digital ocean for IaaS type things and building VMs for projects, but I get the feel digital ocean is marketed more towards individuals/small project use... what's the AWS/Azure equivalent? What would bigger, more highly utilized apps that see much more traffic (FB, Insta, Etc.) run on?
  4. Say a company implements a MEAN/MEVN/MERN/whatever stack for their product, what cloud services might they use to support and deliver a product running on one of these stacks?


Thanks again,
 
We use a ton of different services. On my team we focus on K8s, MQTT, Keyvault, and a few other smaller things. Other teams in our orrg and in the company as a whole use many other services -- load balancers, databases, logging, messaging, storage, AI/ML, basically running the entire gamut. If a team decides they need a certain widget for their product, they simply go use it :).

1) CI/CD is much more than "just" pushing to a repo. It's a complex topic I'm going to massively over simplify here, but, basically, when I merge new config change into our repo, depending on the config spec (i.e. if I'm changing Test config instead of say Prod), then automation takes over, runs tests, builds, and then deploys that change out to the fleet. I literally have to do nothing other than commit the changes and get my PR approved. There's many many ways to hold CI/CD. A crude example would be updating a DOCKERFILE for a container. I make the change to the DOCKERFILE, get it approved and merged into `main`. As soon as that merge completes, the CI/CD automation takes over -- it runs tests to ensure no issues, builds the new container, spins down the instances running the "old" version, spins up containers running the new version, ensures service availability, and then spits out some relevant information into a Slack channel.

2) We don't actively use VMs on my team, nor any team that I know of in my company. They're far too bloated and slow for us. Generally speaking though, you'd use any of the normal tooling out there such as Chef, Puppet, Ansible and so on to spec your VM and then run the tasks to deploy and configure it as you need.

3) I'm not familiar with Digital Ocean. I skimmed their site and it looks like what you said may be accurate. AWS and Azure certainly can do everything Digital Ocean can, and much more. D.O. seems to offer the normal services - VMs, containers, storage, networking, databases. All things I'd expect from anyone wanting to be able to dev and deploy a thing.

4) Again, that's up to the company and team. You can go all-in on cloud services if it benefits your company or your team, or you can do it on-perm. There isn't a one true and correct answer here. There's a lot of mistrust of cloud services, as well as a lot of analysis that would need to go into seeing what path is better, or if a hybrid path works, too. Again, being overly simplistic and general, starting greenfield in a cloud provider is easier than trying to forklift from on-prem to the cloud. So if you have a product that's going through a large version change, that could be an opportunity to migrate and start Version Next in the cloud and leave Version Old on-prem -- if it makes sense to.

My personal opinion is that I find a ton of benefits from using cloud providers. You can certainly do everything on-prem, it's just historically been (A LOT) slower, more costly (in terms of actual $, as well as time and people to build and manage the physical infra), and less agile ("Oh, I need XYZ more of ABC resource, crap, now I need to buy more stuff / work with other team and request it / scale my solution differently due to poor constraints / can't test because no $ for test infra etc. etc.)
 
Man... Software guys are so fast nowadays... no time for hardware. Hope you have deep pockets.
 
Man... Software guys are so fast nowadays... no time for hardware. Hope you have deep pockets.
It's not always more expensive than spending thousands on hardware, power, cooling, cables, etc. plus intangibles like opportunity cost, waiting time and so on. It depends, and each company looking into it should look at both sides and make their call on which way to go.
 
Time, yes, on-prem takes longer. But I worked for one of the biggest insurance companies in the world that has on-prem, and off-prem. I've been in datacenters since 2007. Internally they've tried every cloud provider under the sun. It was never cheaper than using their own facilities. Cloud runs on a meter. Having your own car, if you drive a lot, is always gonna be cheaper then taking a cab everywhere.
 
Time, yes, on-prem takes longer. But I worked for one of the biggest insurance companies in the world that has on-prem, and off-prem. I've been in datacenters since 2007. Internally they've tried every cloud provider under the sun. It was never cheaper than using their own facilities. Cloud runs on a meter. Having your own car, if you drive a lot, is always gonna be cheaper then taking a cab everywhere.
Seem to me hope you have deep pocket is reversed here no.

The bigger (and can afford to have people dedicated into making internal infrastructure and not product) you are the more it can make sense to do it internally it sound like.
 
Last edited:
Seem to me hope you have deep pocket is reversed here no.

The bigger you are the more it can make sense to do it internally it sound like.

The real problem is, IMO (watch the hate flow) is that people are afraid of hardware. Or they just don't want to deal with it, at a minimum. Don't get me wrong, I'm not talking about virtualization. Most efforts are easily virtualized now. But the never ending need to get further and further away from hardware seems odd to me. I realize cloud providers provide instant gratification (and reliability, I'll even give you that). In the end though, if you do something yourself, all things being equal, it usually costs you less.
 
Being deep in the community for 10+ years now, I'd say that's not accurate at all. A LOOOT of devs are hardware enthusiasts as well. Having to have hardware, an Ops team (or SRE, or DevOps) to lifecycle it, etc. will as a whole be more expensive than using a cloud provider where those costs are $0.
 
if you just do exactly what you do on premise in cloud, it’s 30% more expensive. Though lower if you have less than 1000 workloads, just factoring for staff, operations and maintainance.

If you develop services that run in cloud native architectures then it will be far far cheaper but the skills to do that are still not common.

Historically the benefit to developers was getting IT out the way, until everyone realised that’s a really bad idea. These days it’s that you can start picking apart your monoliths and then iterate faster. Plus there is the technology (it’s nothing about cloud as such) that enables much tighter alignment of development environments and tool chains. It also lowers the barriers to doing stuff which gives a lot more technology choices that most companies would have struggled to justify. Want a scalable data warehouse and Kafka messaging. You can be experimenting in 20 minutes.

If you’re talking about aws, play around with lambda, step functions and s3. You’ll work out applications pretty fast. If they’re from enterprise environments I also like to show people aws app flow. It’s hilariously easier to integrate systems.

AppSync is another one that is game changing to app architectures. I crush heavily on it. Watch

If you can I’d recommend watching reinvent videos and if you’ve got time free round thanksgiving just go to Reinvent in Vegas. Follow the dev track, it’s awesome fun and will blow your mind what people are doing.

Azure is also very good but not as developer centric. It’s less build your own, but more limited (good data story though, but fuck azure networking)

GCP is… yeah good data stuff but start with the other two.
 
Azure is also very good but not as developer centric. It’s less build your own, but more limited (good data story though, but fuck azure networking)
Er, what? Have you not used GitHub Actions or Azure DevOps? haha. Wow. That statement is pretty wild and off the mark.
 
Azure Devops is fine, it’s not really that close to azure itself except for aad and the attached services like repos are shit in comparison to just using GitHub. (Pipelines is ok but you end up just using custom agents and at that point its value is diminished).

GitHub actions are great but a bit limited (but getting less so) However it has a strong future, not least becauseit will be replacing pipelines (as the team has been been reassigned)

Don’t really consider ADO as a big benefit of cloud though. Then again my background was in SWE Tools so I probably make light of it because
of that.

Both better than the AWS equivalent, because omfg how slow is code commit. Jesus Christ it kills me.

Microsoft themselves say that they’re not as developer centric for azure, they position to enterprise, that’s their sell-in. Works for them and there are some great services but they position completely different.
 
Cloud is just someone else's data center which offers a wide range of tools, services, and software. For most its better than what there inhouse team can build, maintain, and uptime. Allows our IT team to focus on our customers and get more done with less. Then integrate this with Dev Tools, Automation, security, and so much more you get a one stop shop with a more consistent experience. We are an Azure shop and just dipping our toes into the AWS side to build a one stop shop for our research group. (I work in Higher ED)
 
The company I work for is working on moving a lot of infrastructure to Azure, and they're expecting a ton of savings. In addition to the benefits that have already been listed, another benefit is paying only for what you need at a particular time. If your infrastructure needs fluctuate, with steady demand throughout most the year, but huge peaks at particular parts of the year, then you can plan to scale up at high demand times as needed. Versus if you were running your own hardware, you'd have to purchase around your maximum need, and then have expensive hardware running far under capacity for months at a time.
 
Not if your higher Ed 👍
Are they nicer to EDU's? I've been at two companies now they have tried to tighten the screws on. First one was big enough when they started moving to google, microsoft bent the knee. Second one just moved everything to google, since most is kube it was painless.
 
I think we'll see hybrid clouds being more popular. A lot of companies are fine outsourcing the basic infrastructure to the cloud but might want to keep their proprietary and confidential info in house on an internal server to minimize risk...
 
Back
Top