4 ms·
As a company grows, and especially as the portfolio of code expands, it becomes a necessity to have an "it architect" have the overview of it all, approving cha
by hvidgaard 8y ago
As a company grows, and especially as the portfolio of code expands, it becomes a necessity to have an "it architect" have the overview of it all, approving changes to the interworkings of it all. They also needs to approve tech changes, not because they don't want you to work with cool new stuff, but because they have to guarantee the dependencies pulled in are reasonable.
A big software system is comparable to an aircraft in complexity, and it's not unreasonable to expect it to be handled like this.
- scarface74 8y agoIt doesn’t help when the person serving as your IT Architect doesn’t know AWS, your outsourced AWS support company only knows the netops part of AWS so they built the AWS environment just like you would build an environment on prem, manually (instead of using Cloud Formation), having separate subnets for EC2 instances for Dev vs. prod instead of having entirely separate accounts (ie VPCs), and didn’t know how to use any of the other features of AWS. They decided while I was there to move completely over to AWS from an on prem environment and brought in “consultants” to help us. To be honest, I was the architect responsible for software development for the company but didn’t know AWS from a hole in the wall at the time - but neither did the consultants. I wanted to contract someone on my team that had done development and devops on AWS and was certified. I already had approval to hire developers and my budget would have allowed it. But that was a turf battle. Seeing the writing on the wall, I spent the next six months studying up on AWS even though I couldn’t use any of the services. It took so long to get anything approved and my neck was on the line to deliver the system by a certain date, I just asked for a bunch of large AWS EC2 environments and started using the same tools that I would have used in an on prem environment - Mongo (instead of DynamoDB or ElasticSearch), Consul/Vault for configuration (instead of Parameter Store), Fabio (for “load balancing” with internal services), Nomad for job execution and scheduling (instead of CloudWatch/lambda/Elastic Container Service) etc. They ended up having a run rate on AWS that was much more expensive than if I had used AWS services. But, I followed all of the procedures, had complete control over my environments and servers without touching the AWS console, kept the netops team employed because they had to manage the monstrosity - Consul, Vault, Mongo, and Nomad were clustered. I got my pat on the back for delivering on time and on budget - since the AWS architecture budget fell on the netops team not mine - and got my bonus. Then knowing what POS I was forced to create, I put my AWS certifications, my “successful” project, and my title of “lead software architect” that I negotiated for on my resume and got the hell out of dodge to a smaller company that paid me more where I was able to do everything correctly. Fast forward a little bit, now I’m getting real -all I have to do is sign on the dotted line - lucrative offers for consultant roles for a “cloud architect” position because I’m one of the few people in my market that know AWS from a netops, devops, and development point of view. But I don’t want the stress or travel right now. That’s the way the game has to be played to get ahead. Whether I like it or not....
- hvidgaard 8y agoIt sounds stressful. And I don't doubt that it happens, but that was a case of incompetence, and inability to face the reality of not knowing enough to actually use AWS. It can be perfectly fine, as long as the management know the facts, and decide that budget/deadline of the project is more important than running costs down the line.