40 ms·

I think there's a missing angle from the engineer's point of view. I have no interest in developing skills that are essentially just shallow knowledge of a sin

by zmmmmm 5y ago

I think there's a missing angle from the engineer's point of view. I have no interest in developing skills that are essentially just shallow knowledge of a single proprietary vendor's product brochure. I want to develop skills that are highly transferable, fundamental skills that allow me to continuously build over a career. I also think there is danger here for the profession if engineers allow their skills to be pigeon-holed and segmented that way. It's already the bane of our industry ("oh you only know React, we are looking for a Vue developer ...") that recruiters look at shallow skill segments instead of fundamentals. For that reason if nothing else, I'd always want to work on Plan C - cloud providers as suppliers of standard commodity infrastructure. Possibly in a managed way but still standard things that, after I spend years acquiring knowledge about them, will have some value when I show up at a different cloud provider or need to design for internal infrastructure.

tjr225 5y ago
That seems like pretty much the entire point of containers and/or kubernetes.
- ignoramous 5y ago
  ...and of HashiCorp, more aptly.
  - tjr225 5y ago
    I think HashiCorp is made fairly redundant by Kubernetes, but yes if you don't want to adopt Kubernetes, you're correct. And that’s totally valid. Kubernetes is already multicloud, and you don't need Terraform, Nomad, or Consul if you're using k8s. I would argue Vault is the exception.
antod 5y ago
You touch on a point that has been bothering me for a while. In the 90s I remember what it was like to be in an industry beholden to MS and other proprietary software. I worked for an MS partner and did the cert thing etc but it felt uncomfortable to me. There were lots of people happy to soak in everything MS and ignore everything else. They were basically tiny pawns in a global Microsoft sales strategy. Most of their knowledge was product details, and how to glue multiple MS products together. I switched to the FOSS world to get away from that product focus and lockin. I enjoyed the freedom of evaluating and choosing tools and building things from interchangable layers. I wasn't beholden to any vendor and was part of a community instead. As Linux later grew into a mainstream OS it worked out great for my career too. Now with everything in my circles moving to AWS and moving into higher level managed services with massive lockin, the creeping notion of everything (incl the certified engineers) turning back into proprietary products is reminding me of how I felt in the late 90s about MS. It's all in the name of efficiency, simplicity and value for money. But I'm not seeing it play out like that. Our Infra/Devops/SRE/etc teams seem to be getting ever larger and ever more swamped in ever complexifying CI/CD pipelines and endless freaking IAM policy tweaking and hand holding of self service development teams. Meanwhile the annual AWS bills dwarf our previous on prem colo and hardware replacement budgets (eg 10x), even though we haven't saved anything on staff costs as that has gone way up too. We're back to just gluing vendor products together again, with general purpose tech knowledge being replaced by proprietary product knowledge. And the new generation of engineers and managers that don't remember the 90s see all this as progress and not a problem. I am now an "old man despairs at cloud" meme....
- Dave3of5 5y ago
  Yeah it's history repeating. I've said it before on here and I'll say it again I don't think running on AWS will ever be cheaper than DIY. It's kind of a fallacy and a sales tactic by AWS to tell you how the elasticity of their offering allows you to "save money during the quite hours". I don't think I've ever seen a system that actually does that.
  - acdha 5y ago
    The savings usually come from the corners being cut on DIY solutions: not accounting for the time spent on infrastructure services, skipping various security and monitoring features, sacrificing reliability, etc. You can definitely beat it with certain workloads (e.g. high-volume egress) but I’ve seen more cases where someone thought they had beaten it but was really comparing unlike things (e.g. comparing S3 to unreliable storage in a single location) or leaving out operator time.
    - treis 5y ago
      The counter to this is that companies rarely cut ops staff when moving to the cloud. The problem is that you still have security and monitoring knobs to fiddle with in a cloud. And the staff you had is worse at fiddling with these knobs than the old knobs that they knew well. Plus, you've now added a whole new category of cost optimization problems.
      - acdha 5y ago
        > And the staff you had is worse at fiddling with these knobs than the old knobs that they knew well. Plus, you've now added a whole new category of cost optimization problems. More typically, it makes those problems visible — you get a bill from AWS every month in a way which you don't get a report that 70% of the hardware in your data center is either under-utilized or being used inefficiently. I think cloud migrations often suffer from that as a source of attribution error: “OMG, we don't have perfect security in the cloud!” “Aren't you running a production app on RHEL 6 under the account of someone who left 8 years ago?” “yeah, but we know about that!”
deanCommie 5y ago
There are plenty of PHP developers that focus on PHP careers, C# developers that focus on C# careers. Windows developers that don't develop for Linux, and vice-versa. The cloud providers are just one abstraction above of OS's. AWS is Linux. Azure is Windows. GCP is Mac. No, not really. Just as an analogy of approximate customer market share, and again illustrating that there are plenty of people who could build careers on specializing in only one. Most developers, even. Then there's something like Kubernetes. Which, extending the analogy above, makes me think of HTML5/JavaScript development with Electron - write your logic once, run on any OS (or Cloud Provider). Now Electron is great, and web development is clearly very popular. But would you recommend that from an engineer's point of view, focusing on Web Development and Electron is the only way to build skills that are "highly transferable, fundamental skills"? Now if by transferable skills, you meant actually the underlying OS/networking/infrastructure/data center skills, well then that's A) not really cloud skills, and B) soon will be as niche as C/Assembly programmers - still vital, essential, and widespread - but also a tiny minority.
- ignoramous 5y ago
  > Windows developers that don't develop for Linux, and vice-versa. Heh, the vice-versa reminded me of: A profitable, growing, useful, legal, well-loved... failure (2012), https://apenwarr.ca/log/20120326 https://apenwarr.ca/log/20120326
roland35 5y ago
I understand your point about career vendor lock-in, but I am not sure if it is as big of a problem as you may think. If I were a hiring manager for a team using Google Cloud or Azure and I saw a candidate with a strong background using AWS specific services such as Lambda or DynamoDB I certainly would think they can handle whatever GCP/Azure's versions are too. Heck, AWS in 2022 has changed quite a bit since AWS 2018, so for better or worse we all need to keep our skills fresh even if we are locked in!
moring 5y ago
I found that even a proprietary product can improve your skills in a general way, and it has the advantage of being pre-selected for "what works". Anecdata: Google Firebase, specifically Firestore. On a superficial level, it's just another NoSQL database and you'd probably (rightfully) realize all the things that MongoDB can do that Firebase cannot. OTOH, I learned two things from it that I didn't from previous work with MySQL and PostgreSQL. (Note that I did not previously work with MongoDB beyond some tinkering, so maybe that would work as well). The first was data-change notifications, i.e. getting notified when a record changes. I toyed around with this idea with MySQL some time ago, masquerading my server as a replica server, but generating derived data form it. IIRC PostgreSQL has something similar with WAL streaming. With Firebase, I learned how this can actually work and convinced me that the idea is sound. It definitely encourages me to actually do this for real when I work with PostgreSQL again. The second is what PostgreSQL calls row-level security, i.e. using the data in a row to determine required permissions. In Firestore, this is the only kind of permission control (except for all-in admin accounts), and it showed me how this easily prevents a whole range of security issues that can occur through bugs in a back-end server. The specific coding around Firestore is shallow as you said, and non-transferable, but understanding what is possible is something that will definitely help me in the future, with other databases.
- 2ion 5y ago
  This might be true in some cases. For example, I'd argue that doing a Cisco CCNA/CCNP certification is going to teach people not entirely familiar with the matter a ton of useful stuff about network technology in general even if they go to work on a Juniper site. On the other hand, I've rejected all certs that relate to "_______ certified architect/developer/whatever", most famously pushed in our company as the "AWS certified in-house advertiser". In any case, those certs are extremely lucrative business.
scarface74 5y ago
Disclaimer: I work at AWS in Professional Services take my bias as you will… I’ve been developing professionally for over 25 years and 10 years before that as a hobby. My goal has always been to solve business problems. Infrastructure is just “undifferentiated heavy lifting” to me. At my second job over 20 years ago, we sold hosted storage because we had to and we had to maintain our own SAN, infrastructure, databases, 20 or so application servers, DB servers, etc. That wasn’t part of our core business. Today, a company would never do that themselves. I went from belatedly opening the AWS console in 2018 for the first time, to rearchitecting my previous 60 person company’s entire architecture to be “cloud native” and “serverless” so we could effortlessly scale as we moved into selling access to our microservices to large health care systems. Being able to scale came in handy in 2020 when there was a little worldwide pandemic. They were acquired 6 months after I left for 10x revenue. They weren’t concerned about “cloud lock-in”. My CTO who championed the charge to go all in on AWS - and is still very up to date technically - is in his 50s. Two years later, I got a job at AWS. There is nothing magical about the concepts of learning AWS. Most of the services are just hosted versions of well known open source tools and the rest are conceptually the same as I have done for over 25 years. I didn’t get my job because of the vast knowledge I had about AWS from 2 years working at a 60 person startup (please note sarcasm). I got it because I knew how to lead development and deployments and do “application modernization”. I spent half my loops discussing how I had used Hashicorps Nomad, Consul and Mongo to create a master data model at a company that didn’t use AWS at all. There are plenty of people who are hired in my department who have no prior AWS knowledge. But are subject matter experts in their domains. I’m 100% sure that if I applied for a similar role as mine with MS/Azure or Google/GCP they wouldn’t be deterred from hiring me even though I know nothing about either.
ignoramous 5y ago
>> I think there's a missing angle from the engineer's point of view... I'd always want to work on Plan C - cloud providers as suppliers of standard commodity infrastructure. Possibly in a managed way... tbray did address this point with a different question: So if I'm in technology leadership, one of my key priorities... is something along the lines of "How do I succeed in the face of the talent crisis?" I'll tell you one way: Go all in on a public-cloud platform and use the highest-level serverless tools as much as possible. You'll never get rid of all the operational workload. But every time you reduce the labor around instance counts and pod sizes and table space and file descriptors and patch levels, you've just increased the proportion of your hard-won recruiting wins that go into delivery of business-critical customer-visible features.

by zmmmmm 5y ago

tjr225 5y ago

That seems like pretty much the entire point of containers and/or kubernetes.

ignoramous 5y ago
...and of HashiCorp, more aptly.
- tjr225 5y ago
  I think HashiCorp is made fairly redundant by Kubernetes, but yes if you don't want to adopt Kubernetes, you're correct. And that’s totally valid. Kubernetes is already multicloud, and you don't need Terraform, Nomad, or Consul if you're using k8s. I would argue Vault is the exception.

antod 5y ago

You touch on a point that has been bothering me for a while. In the 90s I remember what it was like to be in an industry beholden to MS and other proprietary software. I worked for an MS partner and did the cert thing etc but it felt uncomfortable to me. There were lots of people happy to soak in everything MS and ignore everything else. They were basically tiny pawns in a global Microsoft sales strategy. Most of their knowledge was product details, and how to glue multiple MS products together. I switched to the FOSS world to get away from that product focus and lockin. I enjoyed the freedom of evaluating and choosing tools and building things from interchangable layers. I wasn't beholden to any vendor and was part of a community instead. As Linux later grew into a mainstream OS it worked out great for my career too. Now with everything in my circles moving to AWS and moving into higher level managed services with massive lockin, the creeping notion of everything (incl the certified engineers) turning back into proprietary products is reminding me of how I felt in the late 90s about MS. It's all in the name of efficiency, simplicity and value for money. But I'm not seeing it play out like that. Our Infra/Devops/SRE/etc teams seem to be getting ever larger and ever more swamped in ever complexifying CI/CD pipelines and endless freaking IAM policy tweaking and hand holding of self service development teams. Meanwhile the annual AWS bills dwarf our previous on prem colo and hardware replacement budgets (eg 10x), even though we haven't saved anything on staff costs as that has gone way up too. We're back to just gluing vendor products together again, with general purpose tech knowledge being replaced by proprietary product knowledge. And the new generation of engineers and managers that don't remember the 90s see all this as progress and not a problem. I am now an "old man despairs at cloud" meme....

Dave3of5 5y ago
Yeah it's history repeating. I've said it before on here and I'll say it again I don't think running on AWS will ever be cheaper than DIY. It's kind of a fallacy and a sales tactic by AWS to tell you how the elasticity of their offering allows you to "save money during the quite hours". I don't think I've ever seen a system that actually does that.
- acdha 5y ago
  The savings usually come from the corners being cut on DIY solutions: not accounting for the time spent on infrastructure services, skipping various security and monitoring features, sacrificing reliability, etc. You can definitely beat it with certain workloads (e.g. high-volume egress) but I’ve seen more cases where someone thought they had beaten it but was really comparing unlike things (e.g. comparing S3 to unreliable storage in a single location) or leaving out operator time.
  - treis 5y ago
    The counter to this is that companies rarely cut ops staff when moving to the cloud. The problem is that you still have security and monitoring knobs to fiddle with in a cloud. And the staff you had is worse at fiddling with these knobs than the old knobs that they knew well. Plus, you've now added a whole new category of cost optimization problems.
    - acdha 5y ago
      > And the staff you had is worse at fiddling with these knobs than the old knobs that they knew well. Plus, you've now added a whole new category of cost optimization problems. More typically, it makes those problems visible — you get a bill from AWS every month in a way which you don't get a report that 70% of the hardware in your data center is either under-utilized or being used inefficiently. I think cloud migrations often suffer from that as a source of attribution error: “OMG, we don't have perfect security in the cloud!” “Aren't you running a production app on RHEL 6 under the account of someone who left 8 years ago?” “yeah, but we know about that!”

deanCommie 5y ago

There are plenty of PHP developers that focus on PHP careers, C# developers that focus on C# careers. Windows developers that don't develop for Linux, and vice-versa. The cloud providers are just one abstraction above of OS's. AWS is Linux. Azure is Windows. GCP is Mac. No, not really. Just as an analogy of approximate customer market share, and again illustrating that there are plenty of people who could build careers on specializing in only one. Most developers, even. Then there's something like Kubernetes. Which, extending the analogy above, makes me think of HTML5/JavaScript development with Electron - write your logic once, run on any OS (or Cloud Provider). Now Electron is great, and web development is clearly very popular. But would you recommend that from an engineer's point of view, focusing on Web Development and Electron is the only way to build skills that are "highly transferable, fundamental skills"? Now if by transferable skills, you meant actually the underlying OS/networking/infrastructure/data center skills, well then that's A) not really cloud skills, and B) soon will be as niche as C/Assembly programmers - still vital, essential, and widespread - but also a tiny minority.

ignoramous 5y ago
> Windows developers that don't develop for Linux, and vice-versa. Heh, the vice-versa reminded me of: A profitable, growing, useful, legal, well-loved... failure (2012), https://apenwarr.ca/log/20120326 https://apenwarr.ca/log/20120326

roland35 5y ago

I understand your point about career vendor lock-in, but I am not sure if it is as big of a problem as you may think. If I were a hiring manager for a team using Google Cloud or Azure and I saw a candidate with a strong background using AWS specific services such as Lambda or DynamoDB I certainly would think they can handle whatever GCP/Azure's versions are too. Heck, AWS in 2022 has changed quite a bit since AWS 2018, so for better or worse we all need to keep our skills fresh even if we are locked in!

moring 5y ago

I found that even a proprietary product can improve your skills in a general way, and it has the advantage of being pre-selected for "what works". Anecdata: Google Firebase, specifically Firestore. On a superficial level, it's just another NoSQL database and you'd probably (rightfully) realize all the things that MongoDB can do that Firebase cannot. OTOH, I learned two things from it that I didn't from previous work with MySQL and PostgreSQL. (Note that I did not previously work with MongoDB beyond some tinkering, so maybe that would work as well). The first was data-change notifications, i.e. getting notified when a record changes. I toyed around with this idea with MySQL some time ago, masquerading my server as a replica server, but generating derived data form it. IIRC PostgreSQL has something similar with WAL streaming. With Firebase, I learned how this can actually work and convinced me that the idea is sound. It definitely encourages me to actually do this for real when I work with PostgreSQL again. The second is what PostgreSQL calls row-level security, i.e. using the data in a row to determine required permissions. In Firestore, this is the only kind of permission control (except for all-in admin accounts), and it showed me how this easily prevents a whole range of security issues that can occur through bugs in a back-end server. The specific coding around Firestore is shallow as you said, and non-transferable, but understanding what is possible is something that will definitely help me in the future, with other databases.

2ion 5y ago
This might be true in some cases. For example, I'd argue that doing a Cisco CCNA/CCNP certification is going to teach people not entirely familiar with the matter a ton of useful stuff about network technology in general even if they go to work on a Juniper site. On the other hand, I've rejected all certs that relate to "_______ certified architect/developer/whatever", most famously pushed in our company as the "AWS certified in-house advertiser". In any case, those certs are extremely lucrative business.

scarface74 5y ago

Disclaimer: I work at AWS in Professional Services take my bias as you will… I’ve been developing professionally for over 25 years and 10 years before that as a hobby. My goal has always been to solve business problems. Infrastructure is just “undifferentiated heavy lifting” to me. At my second job over 20 years ago, we sold hosted storage because we had to and we had to maintain our own SAN, infrastructure, databases, 20 or so application servers, DB servers, etc. That wasn’t part of our core business. Today, a company would never do that themselves. I went from belatedly opening the AWS console in 2018 for the first time, to rearchitecting my previous 60 person company’s entire architecture to be “cloud native” and “serverless” so we could effortlessly scale as we moved into selling access to our microservices to large health care systems. Being able to scale came in handy in 2020 when there was a little worldwide pandemic. They were acquired 6 months after I left for 10x revenue. They weren’t concerned about “cloud lock-in”. My CTO who championed the charge to go all in on AWS - and is still very up to date technically - is in his 50s. Two years later, I got a job at AWS. There is nothing magical about the concepts of learning AWS. Most of the services are just hosted versions of well known open source tools and the rest are conceptually the same as I have done for over 25 years. I didn’t get my job because of the vast knowledge I had about AWS from 2 years working at a 60 person startup (please note sarcasm). I got it because I knew how to lead development and deployments and do “application modernization”. I spent half my loops discussing how I had used Hashicorps Nomad, Consul and Mongo to create a master data model at a company that didn’t use AWS at all. There are plenty of people who are hired in my department who have no prior AWS knowledge. But are subject matter experts in their domains. I’m 100% sure that if I applied for a similar role as mine with MS/Azure or Google/GCP they wouldn’t be deterred from hiring me even though I know nothing about either.

ignoramous 5y ago

>> I think there's a missing angle from the engineer's point of view... I'd always want to work on Plan C - cloud providers as suppliers of standard commodity infrastructure. Possibly in a managed way... tbray did address this point with a different question: So if I'm in technology leadership, one of my key priorities... is something along the lines of "How do I succeed in the face of the talent crisis?" I'll tell you one way: Go all in on a public-cloud platform and use the highest-level serverless tools as much as possible. You'll never get rid of all the operational workload. But every time you reduce the labor around instance counts and pod sizes and table space and file descriptors and patch levels, you've just increased the proportion of your hard-won recruiting wins that go into delivery of business-critical customer-visible features.