[scarface74]

Not to mention that the more physical nature of architecture makes it less flexible than code itself so "architectural" patterns are, as a result, significantly less abstract and complex than coding patterns/algorithms.

This is the reason that software engineers need adult supervision. The fact that you think that modern infrastructure is physical and static displays a lack of experience. There is nothing static about modern cloud infrastructure.

I just had to deploy an API to ECS/Fargate (Docker). We had to determine the best combination of memory/cpu of the Fargate runtime environment and what hardware we wanted to give the ElasticSearch environment. I basically wrote a CloudFormation template (infrastructure as code) that defined the environment and then wrote a Node script that ran the CF template and passed in parameters to vary the hardware environment (cpu/memory). After the environment was created, the script then ran a series of Artillery load tests, recorded the results of the load tests, gathered metrics from CloudWatch and estimated the monthly cost compared to the performance.

We reported that to management to let them decide how much they were willing to spend for the throughout they needed.

I’ve created entire environments with databases, Redis Caches, ECS clusters (think AWS version of EKS), etc as a proof of concept by using CloudFormation deploying code to it, showing management as a demo, and then tearing it all down just by clicking delete until we can come back to it after the contract is signed and then spin it back up with one command.

[crimsonalucard]

>This is the reason that software engineers need adult supervision. The fact that you think that modern infrastructure is physical and static displays a lack of experience. There is nothing static about modern cloud infrastructure.

Note how I said "more physical nature," meaning that it's closer to physical but not completely physical. Either way, all abstractions suffer from leakage from the physical world. Data and processes, while seemingly abstract all occupy physical and temporal space and this fact leaks to all layers of the stack. Thus, technically, everything in the universe including computation is physical and nothing is ever purely a virtual entity.

Honestly, you think I don't know about docker? You think I don't know about the cloud? "Infrastructure as code" oooh buzzwords, you're just using a shittier domain specific language to write something that you can also do with Regular code (such as python, no buzzwords needed).

Give me a break, what web developer doesn't know about the above stuff? None.

>I just had to deploy an API to ECS/Fargate (Docker). We had to determine the best combination of memory/cpu of the Fargate runtime environment and what hardware we wanted to give the ElasticSearch environment. I basically wrote a CloudFormation template (infrastructure as code) that defined the environment and then wrote a Node script that ran the CF template and passed in parameters...................

OK, the stuff you did isn't even usually what a "architect" does. It's devops. An architect just diagrams the boxes and lines and gives it to the devops guy to spit out working infrastructure or a POC. But that's besides the point...

Can you write your own programming language? Can you write your own database? Can you write your own Operating System? These are actual specialties (none of which involve "architecture"), not some garbage made up specialty like "architect." At the very least, if you want to be part of an actual specialty in the IT world you need to build shit and that shit needs to be HARD to build, you can't just do some easy diagraming of a bunch of stuff while acting like you have some superior understanding of the latest architecture pattern you can look up on wikipedia.

[perfectspiral]

>Honestly, you think I don't know about docker? You think I don't know about the cloud? "Infrastructure as code" oooh buzzwords, you're just using a shittier domain specific language to write something that you can also do with Regular code (such as python, no buzzwords needed).

https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect

[idoby]

Well, using general Turing-complete code languages for infra and config vs specialized templates/languages is a legit point of contention in the industry right now, although judging by the style, GP isn't considering the pros and cons of each approach, which include:

* Forcing users to learn a specialized language vs reusing knowledge of a general purpose language

* Inevitable Turing-completeness creep and increasing complexity in specialized languages

* Complexity and difficulty of reasoning about general purpose code (and analyzability)

So GP does have a point. He/she is just not making it very well, I think.

[crimsonalucard]

The tradeoffs you mention are obvious right? I'm just sort of downplaying the huge bragging Scarface was doing when he mentioned he did some cloud formation and "infrastructure as code" because it's really not that impressive.

It's obvious that the logical consequence of using Turing complete languages for devops introduce a lot of complexity into infrastructure and can introduce configuration that executes continuously as well. Bugs that only existed in the application layer now creep into infrastructure. Infinite recursion can now be spinning up infinite instances.

That being said the devops thing was a side detail and that's besides the point. The point is that the role 'software architect' is useless.

[idoby]

Obvious? No, and even less straightforward. Personally I think it's a good thing both kinds of tools exist, because each dev/team/project has different needs and different sensibilities.

Personally, I prefer my configuration to be written in a plain-old language (e.g. Python) instead of a specialized config language (be it YAML or JSON based or whatever). I can test that code, I can reason about it, I can review it for bad stuff like infinite loops (not perfectly, but still), I know how it behaves when diffed and merged, etc.

Regarding software architects: I've seen a few companies where architects are hands-off demigods who prescribe complete architectures without ever having to contend with the results of their decisions. Those companies are, in my experience, few, and tend not to do well.

In a lot of other companies, the role of an architect is very similar to what Herr Scarface describes - individuals with a lot of experience who can make broad decisions based on both experience and data, and leave it to lower ranking engineers to work out the exact details. They do the hard/open-ended stuff and come to conclusions about the broad strokes (e.g. "yeah Redis will work well for this problem, but since you have denormalized data you might need a background process to restore consistency"). This is often called "scoping" and it is the main responsibility and impact of higher-ranking engineers (whether they're called "architects" or not, I personally dislike the term).

[crimsonalucard]

>In a lot of other companies, the role of an architect is very similar to what Herr Scarface describes - individuals with a lot of experience who can make broad decisions based on both experience and data, and leave it to lower ranking engineers to work out the exact details. They do the hard/open-ended stuff and come to conclusions about the broad strokes (e.g. "yeah Redis will work well for this problem, but since you have denormalized data you might need a background process to restore consistency"). This is often called "scoping" and it is the main responsibility and impact of higher-ranking engineers (whether they're called "architects" or not, I personally dislike the term).

It seems like these people are capable but most actually are not. The reason is because they spent too much time in this role so they lose the skills of actually being a software engineer and gain the skills of bullshitting about architecture. So when you "interview" or talk to these people it really sounds like they know they're shit when they don't. The reason is, it's basically their job to talk about technology so they become really good at it, and if an interview doesn't involve a technical coding part, then they'll ace those interviews with flying colors.

If you get down to the nitty gritty and literally ask these guys to perform some very easy coding problem or actually implement a product you will tend to see a very high amount of incompetence.

I work at a startup where we accidentally hired one of these architects. The guy bullshitted his way to the top but we're having a hard time giving him a ticket where he works on the actual product. He's politically maneuvering his way around to only work on proof of concepts and holding irrelevant meetings to talk about architecture. Even roped the CTO in to support his case, which completely pissed off the entire team. Startups need people who can get the job done, not someone who can create a little bullshit bubble so that he can keep his bullshit salary.

This is very similar to someone who's been a CTO for many years. If you don't program, if you don't actually build architecture, you lose your technical skills but you gain bullshitting and management skills. This isn't actually completely bad as a companies need leadership and managers and sans the bullshitting part, leadership is a great skill.

It is completely wrong to assume that "Architecture" is some sort of skillset and that an "Architect" is more technically capable (due to the hire rank) than a typical engineer. Give them the title they deserve, and that is: Ex-engineer/manager.

>Obvious? No, and even less straightforward. Personally I think it's a good thing both kinds of tools exist, because each dev/team/project has different needs and different sensibilities.

It's obvious to me the difference between configuration files and turing complete programs or even python. You can extrapolate the benefits of using python or a configuration file. Have you hit an infinite loop error using python to instantiate instances? Maybe once or maybe zero times, but you can still use your brain to extrapolate that this is a potential problem even when you've hit this problem Zero times.

On a side note, you can also extrapolate that JSON and YAML can be turing complete. It depends on how something interprets it. For example:

   {"fib": {
      "PARAMS": {"y": "float"},
      "BASECASE": [["X", "==", 0 ], [1]]
      "RECURSE": [{"EXECUTE_FUNCTION": {
                      "FUNCTION": "fib",
                      "PARAMS": [["y", "-", 1 ]]
         }}, "+", {"EXECUTE_FUNCTION": {
                      "FUNCTION": "fib",
                      "PARAMS": [["y", "-", 2 ]]
         }}}, 
    "main": {"EXECUTE_FUNCTION": {
                      "FUNCTION": "fib",
                      "PARAMS": [["y", "-", 1 ]]
         }}
   }
 

Awkward yes, but I'm just showing you a way where it can be possible in my garbage/made-up JSON above. Which you can extrapolate from that there probably is a much more elegant way of doing it. All you really need are two features: branching and self-reference. JSON or YAML does not actually preclude something to be not turing complete.

>Personally, I prefer my configuration to be written in a plain-old language (e.g. Python) instead of a specialized config language (be it YAML or JSON based or whatever). I can test that code, I can reason about it, I can review it for bad stuff like infinite loops (not perfectly, but still), I know how it behaves when diffed and merged, etc.

Yeah, I'm kind of in agreement with you here as a personal preference.

[scarface74]

While I agree the pendulum goes both ways - for instance a AWS’s CDK builds templates using your language of choice. How can someone know the tradeoffs without a breadth of experience who thinks they can learn everything they need to know from Wikipedia? “There is no compression algorithm for experience.”

[crimsonalucard]

You don't even know how much experience I have. I'm saying architecture patterns can be learned from Wikipedia not 'everything'.

A devops configuration language (outside the domain of architecture) is not included in this category. Please don't be manipulative and please do not lie.

[crimsonalucard]

Let's stay on topic rather than make passive aggressive comments on my intelligence.

You're implying that my comments are stupid and arrogant. Prove it if you can, let's get to the bottom of whether or not "architects" is a worthless specialty or not. I think you know I'm right and the only thing you have left are personal comments on my intelligence.

[scarface74]

Honestly, I also had a long reply but I thought why bother? You haven’t gotten past the first step to knowing what you don’t know.

We all thought we were the smartest people in the room at one point, you’ll grow out of it too one day.

[crimsonalucard]

>We all thought we were the smartest people in the room at one point, you’ll grow out of it too one day.

Again with the insults.

Why bother? Because you can learn and I can learn. I don't come here to trade insults. I come here to lay down the actual reality of what I see unimpeded by social norms. Yeah I'm sure I touched nerve here, but it's nothing personal, the internet allows me to talk about truths that are uncomfortable and forces me to face those truths as well.

I've been proven wrong tons of times on HN, so I'm hoping that if you disagree, you can prove me wrong and I can learn something and I'll return the favor in turn if you're the one that's actually wrong.

I find that this isn't the case with most people, they don't want to face reality. The fact that you turn to personal insults and have this whole "why bother" attitude seems to me as a cover. You don't bother because you got absolutely Nothing to offer.

[scarface74]

It isn’t intended to be an insult. This thread is veering way off topic but if you think you can learn everything that you need to know by reading a few blog posts and Wikipedia articles, what’s the point? Why ask on HN if as you say everything you need to know you can find from a few blog posts?

As software engineers, we tend to be told especially when we are young that we are all “smart people” (tm). We start to internalize it (believe our own bullshit). But the longer your career is, you realize that the world is full of “smart people” and that your coworkers also came up thinking they were the smartest people in the room.