Years ago a DBA I summoned to a project told me that my DB design was not bad, given that I'm a developer. Then he made it twice as fast by redesigning tables, putting in triggers, etc. (it wasn't a matter of ORM.)
Sadly DBAs are not even on the radar of small to medium projects. If they are ever hired it's too late to take full advantage of their work. The naive DB design of developers is too naive. Somebody could say that a DBA would be a premature optimization, IMHO the reality is that the tooling we are using (especially ORMs and their migrations) are designed to create vanilla DBs and vanilla queries (which are fine in all low volume applications.)
An example from a distant past: I remember when foreign keys were taboo among Rails developers because Rails didn't have a way to express them in its DSL. I added them with manual SQL queries in migrations. I was told they were useless but I kept them in the DB (lately I discovered that many developers don't know SQL and didn't attend to any DB course at university.) Fast forward to a few days ago: a developer of a Django project asked me if we had indices in the database, because he's been told that they could speed up queries. I explained him that Django adds indices in the obvious cases (primary keys and foreign keys), plus I added some on the fields we often use in our queries.
You shouldn’t need a DBA for a small or medium project. Any developer who hasn’t taken the time to learn basic RDMS theory like normalization, indexing, foreign keys, etc. doesn’t take thier craft seriously. Knowing the basics of how databases work is a required skill in almost any implementation.
The issue is “framework developers”. I am not opposed to learning and using frameworks but you should always know at least one level below the framework you are using.
If you are a web developer who uses Angular/React and Bootstrap everyday you should know JavaScript, CSS, and HTML well.
If you use an ORM, you should know enough about how databases work to have a mental model of what the database is doing.
As someone who has had DBA in my job title before, it saddens me to think DBA was needed to explain the importance of foreign keys or indexes (this should be general developer knowledge at this point). As a general rule, any field used in a join or where clause is an index candidate. And foreign keys (along with other constraints) are like type checking in code. They help you not do anything stupid later.
lately I discovered that many developers don't know SQL and didn't attend to any DB course at university
My DB course taught us relational algebra and calculus and you were expected to learn SQL independently.
I am constantly bemused tho’ at the extraordinary lengths some devs will go to to avoid SQL. I’ve known people who will grudgingly do SELECT * FROM table; then extract the one row/column they want on the client. Then they complain that the DB is slow when it’s loadavg is 0.01...
Here's a nice counterpoint.. I was on a project where the chosen database was Vertica. I think everyone assumed the DBA had used columnar style databases in the past. So later we found out the DBA didn't know what a projection was. Projections are the REASON you choose a database like Vertica in an analytics project.
In the end many of the various contracting companies started to work together to work around the DBAs ineptitude and work on ways to speed up performance, including projections. We kept him in the loop, but it just felt like the only thing the DBA cared about was permissions and user accounts. In fact that's the only thing we kept calling him for was one of our accounts would suddenly not work. He was also extremely insistent against tools like Liquibase to keep all environments in sync and standardized. Instead our Dev and QA through prod would all have different tables and columns all over the place because the DBA WAS IN CHARGE OF THAT.
This was a large organization, and 99% inefficient. There IS a reason large companies are trying to run projects like startups. DBAs are often like pizza flippers, whereas developers don't like doing things multiple times.
But it's not DBAs as in database admins that are needed. Every project should start with the correct data architecture and for that you need an architect. There are endless number of projects that eventually failed because the data architecture did not scale. That's due to a programmer who designs the database according to the way that their preferred tool works best, which is usually bad for data.
For any project that requires a database, always start with the method that data will be reported. If a report takes a long time to be generated because of your design, then you need to fix that first.
My experience has been very different. We scaled a project with a naive developer approach on Postgresql and we brought in a DBA when we started getting scaling issues. The few optimizations took the DBA 3 days to setup and we were on our way.
I think the reason DBAs are not hired is because we don't need them as often and for as long as we do devs.
> discovered that many developers don't know SQL and didn't attend to any DB course at university
My school's DB course taught you to build databases. You're expected to learn SQL on your own. And we all did. Not knowing SQL is an ongoing lifestyle choice.
To be fair, it's the combination of DevOps done wrong and Full Stack done wrong that will cause interminable chaos. Like "Agile," it's the given manager and team's understanding and method of implementing DevOps and Full Stack that are the issue.
The term "Full Stack Developer" is especially problematic because taken at it's literal meaning it suggests that a developer should be fully competent at ALL aspects of developing an application, which necessarily include deep understanding of system administration, database administration, tertiary dependency (caching apps like Redis, for example) administration, network infrastructure configuration and maintenance -- all of which are impossible for one person and we haven't even gotten to code yet! I think a different term needs to be coined which implies variability until defined at a given shop. I propose "Wide Area of Responsibility (AOR) Developer" which, for Acme Corp, might mean "Is competent in writing server-side REST endpoints AND managing development/production database schemas AND load balancing traffic to production web servers" whereas at XYZ LLC it might mean "Can develop UX designs in Sketch to customer specs and then code them with HTML, CSS, and a JavaScript framework along with writing the REST endpoints into which back-end developers will connect business logic from myriad systems based on the contract the 'Full Stack Devs' specified for the needs of the UI."
> "A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects."
Interesting. I had never considered full stack to reach into the operations space. I always figured it meant development all the way from the server code to the front-end UI, but it was still 100% confined to code and not the operational aspects of keeping the application running.
This is a necessity in small organisations and a problem in large ones. A problem because they have to have all the keys, like a janitor; and they tend to end up being treated as either janitors or dictators by the rest of the company. Also tends to have a high "bus factor".
(I semi-jokingly have "Full Stack From the Transistors Upwards" written on my CV, because I have at one time or another in the course of employment done everything from chip design to web design; that doesn't mean I'd be happy to do all of them at once.)
The term "Full Stack Developer" is especially problematic because taken at it's literal meaning it suggests that a developer should be fully competent at ALL aspects of developing an application, which necessarily include deep understanding of system administration, database administration, tertiary dependency (caching apps like Redis, for example) administration, network infrastructure configuration and maintenance -- all of which are impossible for one person
Why is that impossible especially in the age of cloud? Infrastructure setup and configuration is just another API.
My knowledge of the full stack may not be wide, but it’s fairly deep. If you tell me I have to design and implement a full web application from scratch with no preexisting infrastructure, I can choose a pretty good set of technologies and best practices to get it done as a cloud hosted implementation all the way from net ops, dev ops (CI/CD), backend RDMS or NoSQL storage, a modern server side language, a web server, and a website.
The only part that would be wanting is the website implementation would be a simplistic Bootstrap UI without any modern front end frameworks. The best I could do right now would be either ASP.Net MVC or Jquery + handlebars. But not knowing a front end framework well enough is just because of lack of time to learn and that’s not what I’m concentrating on now.
As the size of the project grew, I would need to bring in specialists for the web (that’s not my forte) and devops (it would be a waste of my time to manage devops/netops) at scale.
> all of which are impossible for one person and we haven't even gotten to code yet!
impossible is a stretch. harder than it appears perhaps.
If one looks at the original unix devs, this was often the case -
modify the kernel to add a new system call so that your runtime system can do X to enable your application to do Y. A true 'sysadmin' in those days was not a pure-IT person, he was an expert of the systems. It is only with the rise of binary-only systems (e.g. SunOS) and IT commercialization that a 'sysadmin' crystallized into a separate pure-IT task distinct from 'developer'.
In my view, what is called 'DevOps' for the operationally focused, and 'FullStack' for the software focused, is really just a return to this mode of operation, which is what a true 'sysadmin' or 'hacker' already was since the dawn of time.
Let me pose a rhetorical question: Why have all the hot trends in software project process/management for the last 10 years been so risk-prone to being "done wrong"?
The author didn't get DevOps (so don't many companies). It's not about putting developers on-call, it's about taking operational concerns into account early in the design of a piece of software and acknowledging that it's going to do much better in the wild when the people building it are also accountable to making it easy to operate.
Blaming DevOps (or full-stack, for that matter) for a toxic company culture is just too easy.
Exactly so. I'm involved in a DevOps transformation at my company, and have been exposed to the topic over the last few years, including attending the Delivery of Things conference in 2016.
What I've learned is that:
1. DevOps is simple to explain
2. For some reason, everyone has their own idea on what it means, and most of them are wrong
Key points from my perspective:
1. DevOps is an evolution of Agile and so all agile practices are a subset of DevOps. This point obviates the need for any points past number 2 below.
2. It's a process which is supposed to get operational knowledge involved in the development process much earlier to build it right the first time
Its over aim is to combat the fact that you can be proficient in only so many things. As you become more specialized in one area, your time becoming proficient in other areas suffers. So a pure dev is unlikely to know much about QA or Hosting, but that domain knowledge would be valuable for them to have in their daily duties. So you try and implement a process by which they have regular access to where that domain knowledge lives, and can make use of it.
It's really just a way of trying to solve the "Jack of all trades, master of none" problem. Put another way, it shouldn't be shuffling more duties onto the dev to save money on headcounts, but a way of increasing the value (not volume) of a Dev's already high-value work.
Yep. I disagree with the premise that DevOps is only a result of "the multiple technical roles that engineers at start-ups were forced to play due to lack of resources" and is therefore unnecessary, even harmful in larger organisations.
So in larger organizations, people can and should specialise more, and not everyone should be "jack of all trades".
But there is an important lesson in DevOps: owning your software from creation through testing, deployment and observing how it runs in production cases, and being partly responsible for handling Operational issues in it has great benefit. It closes a feedback loop that will greatly benefit your software. It doesn't matter if your organisation is large, that learning from the truth of production is still available to you.
> it's about taking operational concerns into account early in the design of a piece of software and acknowledging that it's going to do much better in the wild when the people building it are also accountable to making it easy to operate.
I agree that it's important to be thinking about these future states and having those conversations from day 1. But, I also think that it's easy to abstract away all of the various pieces and dependencies of some application, because we're sold by cloud providers that this design is "reliable" and "robust" and more generally speaking "a better design." But, what if those things aren't actually needed at that point in an applications life? What problem is really being solved if these things don't present a problem? If the application has a few dozen daily users, why is every single piece of it an AWS service vs. a single AWS EC2 instance? It gets even worse than this, of course. I've seen instances where a team of developers had no idea their application was using ElastiCache and experienced application outages as a result of AWS maintenance windows.
Sometimes, I guess, it just strikes me as putting the cart before the horse. And specifically with AWS (but somehow less so with Heroku or DigitalOcean, in my head).
" If there's a particularly nasty issue that seems to require deep database knowledge, you don't have the liberty of saying "that's not my specialty," and handing it off to a DBA team to investigate. Due to constrained resources, you're forced to take on the role of DBA and fix the issue yourself."
Wow, I'm sooo glad we've come as far as we have. I recall a time where a DBA was literally in charge of creating schemas for a product. Just about everything this person is describing in the article rubs me completely the wrong way. I am all about everyone who can help to try helping. All hands on deck. This article is pretty backwards.
This article was written in 2014 but I can personally attest from my experience it is still just as relevant and true. As the owner / operator of a DevOps As a Service company I see all too often people trying to replace dedicated infrastructure and cloud architecture experts with "Someone who has more of a 70% developer 30% devops background". It's unfair to the person being hired with unrealistic expectations and typically damaging to the company in terms of lost time and productivity.
i know of a company that has defined a position where a single person designs and sets up some technical equipment for two totally different departments led by two different, competing bosses.
this job-holder is routinely overworked and faces extreme demands on their time, requiring on-site presence both early in the morning and late at night. the job-holder must mediate interdepartmental conflict (two bosses). and there's no path to promotion.
the company keeps losing people in this position. it keeps casting a wider net, bringing in people from further and further away.
this is a solid, successful company with a reputation as one of the very best places to work in the county. but it has never bothered to redefine the position into two or more separate jobs. it's just churn and burn.
i'm not sure what the moral is. managers exploit the labor pool until they can't any more. then they look for another labor pool. if that doesn't work they whine and complain that they "can't find workers" to fill their jobs.
The issue is that there are successful people who can all those at the same time. Unfortunately, it requires a lot of study and varied experience. A newcomer can become passable Java developer within realistic timescales, but will require years of experience to be able to contribute at an organization that expects him to perform all those roles.
I have 20 years of experience in IT, 7 as admin (ops), 13 in development. I still spend over half my time on purposeful learning and sometimes find mysef out of depth, catching breath. I don't envy noobs who will have little chance catching up.
Most of the time I hear devops it in reality is a person doing hopefully good job in one area and passable in another and relying heavily on others for everything else.
This assume a developer is not a DBA. Or as if you can't be a good one.
I start with FoxPro. So databases is always first for me... to the point that I "mockup" the app with the database schema first.
So, I'm saying that for some people the database -> app is a straight, natural path. DBAs in the past was more about control the access to a central BD in a MAINFRAME. Modern RDBMS are very easy to administer and optimize.
In fact, I think that learn Java, .NET or C++ is far more harder than learn how use a RDBMS in full...
I think this is essential, and it will progress a bit further. As infrastructure has become automated, and QC has been rethought in response. The developer has been able to acquire those roles for improved development time. However, as coding becomes easier, and more people learn to code. I think another role, the product manager, will acquire the developer role (and all the positions previously acquired underneath that). So ultimately the roles of analysts and product managers will be extremely tech-savvy people who understand their respective businesses extremely well.
Today, a business analyst has a small idea. She presents it, then gets approval. A product manager works with her on the details to integrate it into the product or operation, and a project manager inserts the idea into the development backlog and prioritizes it. In a few months a developer gets around to the task, spends a day building it, and deploys right away, and then the analyst can measure if it has value. In the future, the process could be, a business analyst has a small idea. She presents it, with a plan on how to integrate it, and get's approval. Then she spends a day or three building and deploying it and then measures if it has value.
We've been optimizing Development -> deployment, but in reality what the business cares about is Idea -> Deployment.
> However, as coding becomes easier, and more people learn to code.
The problem is coding WILL eventually become hard again. If things are developed too rapidly, some aspect of development is going to accumulate error, that's going to be a bottleneck eventually when it comes time to automate whatever architectural layer is being 'left behind' as permanent/vital/intrinsic to system functioning.
It's easy to lose the forest for the trees when so many 'radically novel' tools keep popping up as 'solutions'. There are bugs in all of those things and they will accumulate eventually to the point that the 'ease' of development comes to a screeching halt. The bugs may only wind up surfacing in 'ideas', like the idea that one can forever hop skip jump from idea to deployment. Somewhere, something is always being sacrificed as an expense of getting something straight to market. (Soapbox: The sanity of developers gets relegated as an innocuous and trivial side effect. Just throw more money at it, right?)
99% of the 'DevOps' stuff that come across my job search is operations that deal with Azure/Google/AWS management, along with the the rainbow CI/CD tools and has nothing to do with doing actual software development. One head hunter that called today was looking for a "DevOps with Site Reliability Engineering", which entailed dealing with data center electrical stuff.
I particularly love the idea that only developers are talented enough to preform all the roles but no one else is. There is a hierarchy of skill in organisation with developers at the top of it.
I think in a few years, if the complexity of cloud infrastructure management is reduced, and its level of abstraction raised, it might make sense to me developers do this work.
But if I'm trying to build some software app in a complex domain, and the infrastructure tooling requires me to configure network routing rules, CIDR blocks, etc., that seems like a huge failure to me, almost like having the developers grow their own crops for sustenance or something, rather than having people specialize in that and leveraging division of labor.
How so? I just had to setup security groups and subnets to make an implementation I was starting work. Why would I want to wait on the “infrastructure guys” to do it when I could set it up myself in the dev environment test it, create a cloud formation template and if I needed to, run it through the other environments.
When I lay out a new application I'm totally thinking about stuff like network topology because that's part of my security posture with regards to my software, and security is part of application design.
If a developer makes 100K a year, you can pay four developers 100K per year to do 50% development and 50% release management on a single, two-person task. Or, simply hire a release manager at, say, 75K and two developers who develop full-time.
is this a realistic cost savings analysis? my impression has been that companies don't hire four developers to do a two-person task. they simply hire one "full-stack developer" to do everything. problem solved, money saved, i'm a great CEO.
The problem with DevOps and other vaguely defined concepts is that the interpretation is entirely up to your management. On one hand, heavy investment into automation and having devs involved in production ops is a good thing. It makes things go faster and puts devs skin in the game. On the other hand, when your manager thinks that DevOps is about having senior scala devs fix printers, you might be in trouble
Task-switching is expensive, but human-to-human communication is more so. As one of those "bright" developers, I'd far rather just do the deployment myself than hand it over to someone less skilled so I can focus on doing more coding, because that's only going to mean I then get interrupted when there's a problem with the deployment.
This, exactly. This is basically the entire pitch for my DevOps as a Service business. Let your developers focus on the core product, we'll handle the infrastructure. I don't think employers always realize the productivity and benefits of letting their developers truly focus.
I used to avoid the DevOps title and called myself just straight Operations. But recently, and I mean within the last week or two, I realized I'm squarely in DevOps territory.
The system I Op runs really smoothly. Problems are infrequent. So instead of spending my time fighting fires, I'm instead working on our next generation infrastructure, running experiments with Kubernetes and Kafka and Influxdb and Elasticsearch.
I'm not developing on our main product most of the time. But I am developing our infrastructure.
As far as the totem pole with developers at the top, able to do all the other jobs? That has not been my experience. In 30 years, working with probably 100+ companies large and small (for 18 years I did contract SysAdmin), I'd say that the developer who even thinks about ops is extremely rare, less than 10%.
I agree that DevOps is more important for smaller companies, and that specialization is useful. I haven't seen evidence that supports the totem pole portion of that post.
The more I think about it, how can a modern developer not know devops? How do you communicate with the devops folks? When I’m fighting software, I create my build scripts (currently a yml file for AWS CodeBuild) as part of the repo. I don’t use Docker but wouldn’t the developer create the build streps for the Docker image?
When I am working on an implementation that can be deployed with CloudFornation,I create the template test it and hand it over to the Dev ops guys. Even if I’m not doing the actually deployments to any environment besides Dev. I still need to know how to.
The same is true for database deployments and upgrades. How do you upgrade a database through CI without knowing SQL?
> The increasing scope of responsibility of the "developer" (whether or not that term is even appropriate anymore is debatable) has given rise to a chimera-like job candidate: the "full-stack" developer. Such a developer is capable of doing the job of developer, QA team member, operations analyst, sysadmin, and DBA.
Is this really what a full-stack developer is understood to be? I'd always assumed it was just someone who was comfortable doing both frontend and backend development on the same project.
Groan. Instead of a rising tide lifting all boats... some devs insist on being divers. Nobody is turning down amazing specialists, but if you aren't a 90th percentile specialist you should probably know a little of everything.
Was the industry so pleased with the timelines and reliability of software projects a few years back that it seemed sensible to heap another career field's worth of complexity onto the developers?
[+] [-] pmontra|7 years ago|reply
Years ago a DBA I summoned to a project told me that my DB design was not bad, given that I'm a developer. Then he made it twice as fast by redesigning tables, putting in triggers, etc. (it wasn't a matter of ORM.)
Sadly DBAs are not even on the radar of small to medium projects. If they are ever hired it's too late to take full advantage of their work. The naive DB design of developers is too naive. Somebody could say that a DBA would be a premature optimization, IMHO the reality is that the tooling we are using (especially ORMs and their migrations) are designed to create vanilla DBs and vanilla queries (which are fine in all low volume applications.)
An example from a distant past: I remember when foreign keys were taboo among Rails developers because Rails didn't have a way to express them in its DSL. I added them with manual SQL queries in migrations. I was told they were useless but I kept them in the DB (lately I discovered that many developers don't know SQL and didn't attend to any DB course at university.) Fast forward to a few days ago: a developer of a Django project asked me if we had indices in the database, because he's been told that they could speed up queries. I explained him that Django adds indices in the obvious cases (primary keys and foreign keys), plus I added some on the fields we often use in our queries.
[+] [-] scarface74|7 years ago|reply
The issue is “framework developers”. I am not opposed to learning and using frameworks but you should always know at least one level below the framework you are using.
If you are a web developer who uses Angular/React and Bootstrap everyday you should know JavaScript, CSS, and HTML well.
If you use an ORM, you should know enough about how databases work to have a mental model of what the database is doing.
[+] [-] matwood|7 years ago|reply
As someone who has had DBA in my job title before, it saddens me to think DBA was needed to explain the importance of foreign keys or indexes (this should be general developer knowledge at this point). As a general rule, any field used in a join or where clause is an index candidate. And foreign keys (along with other constraints) are like type checking in code. They help you not do anything stupid later.
[+] [-] gaius|7 years ago|reply
My DB course taught us relational algebra and calculus and you were expected to learn SQL independently.
I am constantly bemused tho’ at the extraordinary lengths some devs will go to to avoid SQL. I’ve known people who will grudgingly do SELECT * FROM table; then extract the one row/column they want on the client. Then they complain that the DB is slow when it’s loadavg is 0.01...
[+] [-] rhacker|7 years ago|reply
In the end many of the various contracting companies started to work together to work around the DBAs ineptitude and work on ways to speed up performance, including projections. We kept him in the loop, but it just felt like the only thing the DBA cared about was permissions and user accounts. In fact that's the only thing we kept calling him for was one of our accounts would suddenly not work. He was also extremely insistent against tools like Liquibase to keep all environments in sync and standardized. Instead our Dev and QA through prod would all have different tables and columns all over the place because the DBA WAS IN CHARGE OF THAT.
This was a large organization, and 99% inefficient. There IS a reason large companies are trying to run projects like startups. DBAs are often like pizza flippers, whereas developers don't like doing things multiple times.
[+] [-] thewileyone|7 years ago|reply
But it's not DBAs as in database admins that are needed. Every project should start with the correct data architecture and for that you need an architect. There are endless number of projects that eventually failed because the data architecture did not scale. That's due to a programmer who designs the database according to the way that their preferred tool works best, which is usually bad for data.
For any project that requires a database, always start with the method that data will be reported. If a report takes a long time to be generated because of your design, then you need to fix that first.
[+] [-] xutopia|7 years ago|reply
I think the reason DBAs are not hired is because we don't need them as often and for as long as we do devs.
[+] [-] hashkb|7 years ago|reply
My school's DB course taught you to build databases. You're expected to learn SQL on your own. And we all did. Not knowing SQL is an ongoing lifestyle choice.
[+] [-] krainboltgreene|7 years ago|reply
What? Relationships (and thus foreign keys) have been around since before 1.2.
[+] [-] mikece|7 years ago|reply
The term "Full Stack Developer" is especially problematic because taken at it's literal meaning it suggests that a developer should be fully competent at ALL aspects of developing an application, which necessarily include deep understanding of system administration, database administration, tertiary dependency (caching apps like Redis, for example) administration, network infrastructure configuration and maintenance -- all of which are impossible for one person and we haven't even gotten to code yet! I think a different term needs to be coined which implies variability until defined at a given shop. I propose "Wide Area of Responsibility (AOR) Developer" which, for Acme Corp, might mean "Is competent in writing server-side REST endpoints AND managing development/production database schemas AND load balancing traffic to production web servers" whereas at XYZ LLC it might mean "Can develop UX designs in Sketch to customer specs and then code them with HTML, CSS, and a JavaScript framework along with writing the REST endpoints into which back-end developers will connect business logic from myriad systems based on the contract the 'Full Stack Devs' specified for the needs of the UI."
Just a thought.
[+] [-] vkjv|7 years ago|reply
-Robert A. Heinlein
[+] [-] rootusrootus|7 years ago|reply
[+] [-] pjc50|7 years ago|reply
This is a necessity in small organisations and a problem in large ones. A problem because they have to have all the keys, like a janitor; and they tend to end up being treated as either janitors or dictators by the rest of the company. Also tends to have a high "bus factor".
(I semi-jokingly have "Full Stack From the Transistors Upwards" written on my CV, because I have at one time or another in the course of employment done everything from chip design to web design; that doesn't mean I'd be happy to do all of them at once.)
[+] [-] scarface74|7 years ago|reply
Why is that impossible especially in the age of cloud? Infrastructure setup and configuration is just another API.
My knowledge of the full stack may not be wide, but it’s fairly deep. If you tell me I have to design and implement a full web application from scratch with no preexisting infrastructure, I can choose a pretty good set of technologies and best practices to get it done as a cloud hosted implementation all the way from net ops, dev ops (CI/CD), backend RDMS or NoSQL storage, a modern server side language, a web server, and a website.
The only part that would be wanting is the website implementation would be a simplistic Bootstrap UI without any modern front end frameworks. The best I could do right now would be either ASP.Net MVC or Jquery + handlebars. But not knowing a front end framework well enough is just because of lack of time to learn and that’s not what I’m concentrating on now.
As the size of the project grew, I would need to bring in specialists for the web (that’s not my forte) and devops (it would be a waste of my time to manage devops/netops) at scale.
[+] [-] cat199|7 years ago|reply
impossible is a stretch. harder than it appears perhaps.
If one looks at the original unix devs, this was often the case - modify the kernel to add a new system call so that your runtime system can do X to enable your application to do Y. A true 'sysadmin' in those days was not a pure-IT person, he was an expert of the systems. It is only with the rise of binary-only systems (e.g. SunOS) and IT commercialization that a 'sysadmin' crystallized into a separate pure-IT task distinct from 'developer'.
In my view, what is called 'DevOps' for the operationally focused, and 'FullStack' for the software focused, is really just a return to this mode of operation, which is what a true 'sysadmin' or 'hacker' already was since the dawn of time.
[+] [-] forgottenpass|7 years ago|reply
Let me pose a rhetorical question: Why have all the hot trends in software project process/management for the last 10 years been so risk-prone to being "done wrong"?
[+] [-] jupp0r|7 years ago|reply
Blaming DevOps (or full-stack, for that matter) for a toxic company culture is just too easy.
[+] [-] habeebtc|7 years ago|reply
What I've learned is that:
1. DevOps is simple to explain
2. For some reason, everyone has their own idea on what it means, and most of them are wrong
Key points from my perspective:
1. DevOps is an evolution of Agile and so all agile practices are a subset of DevOps. This point obviates the need for any points past number 2 below.
2. It's a process which is supposed to get operational knowledge involved in the development process much earlier to build it right the first time
Its over aim is to combat the fact that you can be proficient in only so many things. As you become more specialized in one area, your time becoming proficient in other areas suffers. So a pure dev is unlikely to know much about QA or Hosting, but that domain knowledge would be valuable for them to have in their daily duties. So you try and implement a process by which they have regular access to where that domain knowledge lives, and can make use of it.
It's really just a way of trying to solve the "Jack of all trades, master of none" problem. Put another way, it shouldn't be shuffling more duties onto the dev to save money on headcounts, but a way of increasing the value (not volume) of a Dev's already high-value work.
[+] [-] SideburnsOfDoom|7 years ago|reply
So in larger organizations, people can and should specialise more, and not everyone should be "jack of all trades".
But there is an important lesson in DevOps: owning your software from creation through testing, deployment and observing how it runs in production cases, and being partly responsible for handling Operational issues in it has great benefit. It closes a feedback loop that will greatly benefit your software. It doesn't matter if your organisation is large, that learning from the truth of production is still available to you.
[+] [-] scruple|7 years ago|reply
I agree that it's important to be thinking about these future states and having those conversations from day 1. But, I also think that it's easy to abstract away all of the various pieces and dependencies of some application, because we're sold by cloud providers that this design is "reliable" and "robust" and more generally speaking "a better design." But, what if those things aren't actually needed at that point in an applications life? What problem is really being solved if these things don't present a problem? If the application has a few dozen daily users, why is every single piece of it an AWS service vs. a single AWS EC2 instance? It gets even worse than this, of course. I've seen instances where a team of developers had no idea their application was using ElastiCache and experienced application outages as a result of AWS maintenance windows.
Sometimes, I guess, it just strikes me as putting the cart before the horse. And specifically with AWS (but somehow less so with Heroku or DigitalOcean, in my head).
[+] [-] joeldg|7 years ago|reply
[deleted]
[+] [-] rhacker|7 years ago|reply
Wow, I'm sooo glad we've come as far as we have. I recall a time where a DBA was literally in charge of creating schemas for a product. Just about everything this person is describing in the article rubs me completely the wrong way. I am all about everyone who can help to try helping. All hands on deck. This article is pretty backwards.
[+] [-] jwitko|7 years ago|reply
[+] [-] HillaryBriss|7 years ago|reply
this job-holder is routinely overworked and faces extreme demands on their time, requiring on-site presence both early in the morning and late at night. the job-holder must mediate interdepartmental conflict (two bosses). and there's no path to promotion.
the company keeps losing people in this position. it keeps casting a wider net, bringing in people from further and further away.
this is a solid, successful company with a reputation as one of the very best places to work in the county. but it has never bothered to redefine the position into two or more separate jobs. it's just churn and burn.
i'm not sure what the moral is. managers exploit the labor pool until they can't any more. then they look for another labor pool. if that doesn't work they whine and complain that they "can't find workers" to fill their jobs.
[+] [-] lmilcin|7 years ago|reply
I have 20 years of experience in IT, 7 as admin (ops), 13 in development. I still spend over half my time on purposeful learning and sometimes find mysef out of depth, catching breath. I don't envy noobs who will have little chance catching up.
Most of the time I hear devops it in reality is a person doing hopefully good job in one area and passable in another and relying heavily on others for everything else.
[+] [-] mamcx|7 years ago|reply
This assume a developer is not a DBA. Or as if you can't be a good one.
I start with FoxPro. So databases is always first for me... to the point that I "mockup" the app with the database schema first.
So, I'm saying that for some people the database -> app is a straight, natural path. DBAs in the past was more about control the access to a central BD in a MAINFRAME. Modern RDBMS are very easy to administer and optimize.
In fact, I think that learn Java, .NET or C++ is far more harder than learn how use a RDBMS in full...
[+] [-] swalsh|7 years ago|reply
Today, a business analyst has a small idea. She presents it, then gets approval. A product manager works with her on the details to integrate it into the product or operation, and a project manager inserts the idea into the development backlog and prioritizes it. In a few months a developer gets around to the task, spends a day building it, and deploys right away, and then the analyst can measure if it has value. In the future, the process could be, a business analyst has a small idea. She presents it, with a plan on how to integrate it, and get's approval. Then she spends a day or three building and deploying it and then measures if it has value.
We've been optimizing Development -> deployment, but in reality what the business cares about is Idea -> Deployment.
[+] [-] s-shellfish|7 years ago|reply
The problem is coding WILL eventually become hard again. If things are developed too rapidly, some aspect of development is going to accumulate error, that's going to be a bottleneck eventually when it comes time to automate whatever architectural layer is being 'left behind' as permanent/vital/intrinsic to system functioning.
It's easy to lose the forest for the trees when so many 'radically novel' tools keep popping up as 'solutions'. There are bugs in all of those things and they will accumulate eventually to the point that the 'ease' of development comes to a screeching halt. The bugs may only wind up surfacing in 'ideas', like the idea that one can forever hop skip jump from idea to deployment. Somewhere, something is always being sacrificed as an expense of getting something straight to market. (Soapbox: The sanity of developers gets relegated as an innocuous and trivial side effect. Just throw more money at it, right?)
[+] [-] HillaryBriss|7 years ago|reply
I would add, respectfully, that this has been "the future" for longer than I can remember.
[+] [-] cleong|7 years ago|reply
[+] [-] xellisx|7 years ago|reply
[+] [-] lhopki01|7 years ago|reply
[+] [-] arwhatever|7 years ago|reply
But if I'm trying to build some software app in a complex domain, and the infrastructure tooling requires me to configure network routing rules, CIDR blocks, etc., that seems like a huge failure to me, almost like having the developers grow their own crops for sustenance or something, rather than having people specialize in that and leveraging division of labor.
[+] [-] scarface74|7 years ago|reply
[+] [-] eropple|7 years ago|reply
Your infrastructure is part of your software.
[+] [-] HillaryBriss|7 years ago|reply
is this a realistic cost savings analysis? my impression has been that companies don't hire four developers to do a two-person task. they simply hire one "full-stack developer" to do everything. problem solved, money saved, i'm a great CEO.
[+] [-] scarface74|7 years ago|reply
[+] [-] AzzieElbab|7 years ago|reply
[+] [-] lmm|7 years ago|reply
[+] [-] jwitko|7 years ago|reply
[+] [-] dsr_|7 years ago|reply
When you have a dozen developers working on the same project, doing the deployment yourself is a danger to the company.
[+] [-] throwaway151514|7 years ago|reply
I'm mostly in Ops and I often find myself getting handed something from less skilled developers to run in production. It's frustrating too.
[+] [-] linsomniac|7 years ago|reply
The system I Op runs really smoothly. Problems are infrequent. So instead of spending my time fighting fires, I'm instead working on our next generation infrastructure, running experiments with Kubernetes and Kafka and Influxdb and Elasticsearch.
I'm not developing on our main product most of the time. But I am developing our infrastructure.
As far as the totem pole with developers at the top, able to do all the other jobs? That has not been my experience. In 30 years, working with probably 100+ companies large and small (for 18 years I did contract SysAdmin), I'd say that the developer who even thinks about ops is extremely rare, less than 10%.
I agree that DevOps is more important for smaller companies, and that specialization is useful. I haven't seen evidence that supports the totem pole portion of that post.
[+] [-] jiveturkey|7 years ago|reply
[+] [-] scarface74|7 years ago|reply
When I am working on an implementation that can be deployed with CloudFornation,I create the template test it and hand it over to the Dev ops guys. Even if I’m not doing the actually deployments to any environment besides Dev. I still need to know how to.
The same is true for database deployments and upgrades. How do you upgrade a database through CI without knowing SQL?
[+] [-] 394549|7 years ago|reply
Is this really what a full-stack developer is understood to be? I'd always assumed it was just someone who was comfortable doing both frontend and backend development on the same project.
[+] [-] arwhatever|7 years ago|reply
But you lose a lot of expertise when you spread your developers too widely, technology-wise.
[+] [-] hashkb|7 years ago|reply
[+] [-] arwhatever|7 years ago|reply