I am a professional DevOps Engineer with a demonstrated history of working in the internet industry. I am an avid Linux lover and supporter of the open-source movement philosophy.
Location
Sofia, Bulgaria
Work
Developer Advocate at Materialize | Community Manager at DigitalOcean | Co-Founder at DevDojo
I would personally suggest a little bit of both and then you transaction into the one that brings you more joy. If you end up linking both, that's even better.
I would also add DevOps to the list. Frontend vs Backend vs Fullstack vs DevOps, just created a poll for that:
When you say "Frontend vs Backend vs Fullstack vs DevOps" it's actually not devops, it's just ops. Devops is a practice that brings all areas together.
I am a professional DevOps Engineer with a demonstrated history of working in the internet industry. I am an avid Linux lover and supporter of the open-source movement philosophy.
Location
Sofia, Bulgaria
Work
Developer Advocate at Materialize | Community Manager at DigitalOcean | Co-Founder at DevDojo
Depends - any engineer they in a team that practices devops is theoretically a devops engineer (regardless whether you do backend or ops or something else). Ken Mugrage (kenmugrage.com/), one of the guys who helped coin and define the term (though not the originator or the idea) always goes at great pains to emphasize that devops is a practice and not a role (still doesn't prevent recruiters from using it as a synonym for ops, as it sounds more modern)
I am a professional DevOps Engineer with a demonstrated history of working in the internet industry. I am an avid Linux lover and supporter of the open-source movement philosophy.
Location
Sofia, Bulgaria
Work
Developer Advocate at Materialize | Community Manager at DigitalOcean | Co-Founder at DevDojo
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
Roles in project development career path simplified:
BackEnd
FrontEnd
SysAdmin
DBAdmin
Then you can invent jobs specialised in a single thing such "test engineer... is someone who writes down tests" (ok but usually devs should write them so...) you can even go deeper and say "front end test engineer".
The same happen with DevOps and other stuff.
The only role that is not so common as it's needed to be in the industry is the person who design into HTML+CSS (layout designer).
The issue here is most of time this people studied and worked with design but not specifically with web design (or software UI design) so you need someone to translate it's designs (most of time made in Adobe XD, Sketch, Illustrator, Photoshop or something worse) into code.
This is a harmful process that burns devs who pick this job and the designers who are designing products-for-code without coding knowledge.
One role feels like he's hitting a silly wall that does not understand how the things work on an engineered product and the other feels like it's own creativity is melted down.
This does not happen with other engineered products such a car, on which a designer will make a concept and then the engineers will modify to match the required specifications. On the other hand, in the IT world seems that engineers have to apply a design without further analysis and modification so it harms performance, usability, SEO and much more.
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
apart of being more an infrastructure thing, DevOps is something you usually don't start with, the reason is you need to understand the dev process to ensure a fluent software transition from dev to test/prod environment.
So it's something that usually devs do (that's the Dev in the word) on small/medium teams and that only largest teams or companies with complicated (most of time over-engineered) builds are in need to specify this role on a person or two.
The other part is SysAdmin's stuff (when the code reach the desired stage it must work well with a well defined and profiled server, it's monitoring and so), but you're a sysadmin so you know what i'm talking about.
At the end all devs need to be a little "full stack" to understand the entire process if you expect to do something else apart from coding little pieces of code inside a software you don't know at all. Maybe i'm seeing that from an engineering point of view and this can be avoided for self-learners and newcomers but I would recommend it as well as I recommend to push hard into knowing the environment where your code is running (for a web dev: JS engine, DOM and CSSOM, compilers, interpreters, networking, different servers and what they offer, how to set up a simple env and so) so you can build better code.
apart of being more an infrastructure thing, DevOps is something you usually don't start with, the reason is you need to understand the dev process to ensure a fluent software transition from dev to test/prod environment.
Oh? What if a feature has a perfect use case for serverless? Thinking about infrastructure up front has huge benefits because you end up with a better architecture.
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
Having a better architecture is that one that fits better into your project, so if you're developing a serverless app you'll know how to take care of the desired and required software needs.
But wait... you know that serverless does not mean "without server" on a literal way, do you? xD
It's an execution model where the provider (AWS, Azure, Google Cloud...) is responsible for executing fragments of code while dynamically assigning resources.
While serverless abstracts the underlying infrastructure to the developer, the servers still participate in the execution of our functions.
By this means, it's still infrastructure but you subcontract a provider to be "your sysadmin".
Apart from that I understand that one of both (you and me) made a mistake (me writing or you reading).
When I said "DevOps is something you usually don't start with" I mean when learning to be part of project development process for the first time. If you know nothing or few about how do you would manage to find out which architecture do you need? And moreover, having a serverless, or a cloud, or a VPS or having Apache, or Nginx or whatever server you need in the architecture is not part of the Dev on the DevOps.
As said 90183710273 times, DevOps is a blend of practices and not a job, some parts rely on Devs, some parts rely on Ops. I wrote a detailed post about that some time ago: dev.to/joelbonetr/all-you-need-to-...
Please, tell me if you find out any inconsistency.
Having a better architecture is that one that fits better into your project, so if you're developing a serverless app you'll know how to take care of the desired and required software needs.
Building an application which is entirely serverless isn't the only use case.. IMO the best use case for serverless is when you have ad hock operations which need to be handled, such as indound emails, periodic jobs, etc. This is because these operations are short lived and don't necessarily need a server of up at all times.
These kinds of decisions affect how the code is implemented as well as the infrastructure costs. It is better to consider them sooner than later.
But wait... you know that serverless does not mean "without server" on a literal way, do you? xD
Yes I am aware.
As said 90183710273 times, DevOps is a blend of practices and not a job, some parts rely on Devs, some parts rely on Ops. I wrote a detailed post about that some time ago:
I am also aware of this. I did not speak of devops, I spoke of the infrastructure. Not thinking of the infrastructure as part of the development process is antithetic to devops.
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
did you just avoid the context of "newcomers that start learning to code" another time?
Yes I've used "serverless" with Google Cloud Functions for example and yes it was about triggers when calls came into the switchboard on a specific company but... Holly cow! It seems an add to serverless more than a reliable comment about a topic. Please read the title of the post and understand the context where we are discussing in.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I would personally suggest a little bit of both and then you transaction into the one that brings you more joy. If you end up linking both, that's even better.
I would also add DevOps to the list. Frontend vs Backend vs Fullstack vs DevOps, just created a poll for that:
twitter.com/bobbyiliev_/status/139...
When you say "Frontend vs Backend vs Fullstack vs DevOps" it's actually not devops, it's just ops. Devops is a practice that brings all areas together.
True. But you could still be a DevOps Engineer right?
Depends - any engineer they in a team that practices devops is theoretically a devops engineer (regardless whether you do backend or ops or something else). Ken Mugrage (kenmugrage.com/), one of the guys who helped coin and define the term (though not the originator or the idea) always goes at great pains to emphasize that devops is a practice and not a role (still doesn't prevent recruiters from using it as a synonym for ops, as it sounds more modern)
Very good points! I guess that I was going with the trend but you are right that the question should be rephrased to Ops or SRE rahther than DevOps.
Roles in project development career path simplified:
Then you can invent jobs specialised in a single thing such "test engineer... is someone who writes down tests" (ok but usually devs should write them so...) you can even go deeper and say "front end test engineer".
The same happen with DevOps and other stuff.
The only role that is not so common as it's needed to be in the industry is the person who design into HTML+CSS (layout designer).
The issue here is most of time this people studied and worked with design but not specifically with web design (or software UI design) so you need someone to translate it's designs (most of time made in Adobe XD, Sketch, Illustrator, Photoshop or something worse) into code.
This is a harmful process that burns devs who pick this job and the designers who are designing products-for-code without coding knowledge.
One role feels like he's hitting a silly wall that does not understand how the things work on an engineered product and the other feels like it's own creativity is melted down.
This does not happen with other engineered products such a car, on which a designer will make a concept and then the engineers will modify to match the required specifications. On the other hand, in the IT world seems that engineers have to apply a design without further analysis and modification so it harms performance, usability, SEO and much more.
just a thought, i'm back to work :D
apart of being more an infrastructure thing, DevOps is something you usually don't start with, the reason is you need to understand the dev process to ensure a fluent software transition from dev to test/prod environment.
So it's something that usually devs do (that's the Dev in the word) on small/medium teams and that only largest teams or companies with complicated (most of time over-engineered) builds are in need to specify this role on a person or two.
The other part is SysAdmin's stuff (when the code reach the desired stage it must work well with a well defined and profiled server, it's monitoring and so), but you're a sysadmin so you know what i'm talking about.
At the end all devs need to be a little "full stack" to understand the entire process if you expect to do something else apart from coding little pieces of code inside a software you don't know at all. Maybe i'm seeing that from an engineering point of view and this can be avoided for self-learners and newcomers but I would recommend it as well as I recommend to push hard into knowing the environment where your code is running (for a web dev: JS engine, DOM and CSSOM, compilers, interpreters, networking, different servers and what they offer, how to set up a simple env and so) so you can build better code.
Oh? What if a feature has a perfect use case for serverless? Thinking about infrastructure up front has huge benefits because you end up with a better architecture.
Having a better architecture is that one that fits better into your project, so if you're developing a serverless app you'll know how to take care of the desired and required software needs.
But wait... you know that serverless does not mean "without server" on a literal way, do you? xD
It's an execution model where the provider (AWS, Azure, Google Cloud...) is responsible for executing fragments of code while dynamically assigning resources.
While serverless abstracts the underlying infrastructure to the developer, the servers still participate in the execution of our functions.
By this means, it's still infrastructure but you subcontract a provider to be "your sysadmin".
Apart from that I understand that one of both (you and me) made a mistake (me writing or you reading).
When I said "DevOps is something you usually don't start with" I mean when learning to be part of project development process for the first time. If you know nothing or few about how do you would manage to find out which architecture do you need? And moreover, having a serverless, or a cloud, or a VPS or having Apache, or Nginx or whatever server you need in the architecture is not part of the Dev on the DevOps.
As said 90183710273 times, DevOps is a blend of practices and not a job, some parts rely on Devs, some parts rely on Ops. I wrote a detailed post about that some time ago:
dev.to/joelbonetr/all-you-need-to-...
Please, tell me if you find out any inconsistency.
Building an application which is entirely serverless isn't the only use case.. IMO the best use case for serverless is when you have ad hock operations which need to be handled, such as indound emails, periodic jobs, etc. This is because these operations are short lived and don't necessarily need a server of up at all times.
These kinds of decisions affect how the code is implemented as well as the infrastructure costs. It is better to consider them sooner than later.
Yes I am aware.
I am also aware of this. I did not speak of devops, I spoke of the infrastructure. Not thinking of the infrastructure as part of the development process is antithetic to devops.
did you just avoid the context of "newcomers that start learning to code" another time?
Yes I've used "serverless" with Google Cloud Functions for example and yes it was about triggers when calls came into the switchboard on a specific company but... Holly cow! It seems an add to serverless more than a reliable comment about a topic. Please read the title of the post and understand the context where we are discussing in.