Jumziey
I've seen so many projects bending over backwards to avoid k8s and pay large cloud bills to avoid it at all costs. (ECS and app services are hopelessly expensive and bothersome)
K8s is really good, pretty easy to maintain, but a bit hard to understand. Mostly because distributed, zero down time systems are a bit hard to get by nature. But if you have someone that wants to take it on I've managed k8s clusters, solo, without incident, while doing lots of other stuff too (working with larger teams now though). Not to mention there's a lot of competence out there that can take over if I'd move on. Most of the deep complexity comes with more advance use cases, that wont show up for smaller deployments.
That said, no h8 towards going your own way! If your a solo developer (or small team) for a smallish project, don't feel the absolute need. If you get to the point you need it you should be earning enough to start paying someone to help ya get your app to a distributed system like k8s.
I think it's good to invest the time in understanding k8s though as a professional. Even if you won't directly run it it teaches you a lot about how to think about distributed, zero downtime systems. And what requirements that puts on an app.
Just want to give it a shout out in this context, same tech and quite mature. Been using it successfully at work for remote pair programming and it feels like your looking at your co workers screen
Granted just used in a home setting running smaller workloads for backups, private projects, git etc.
Ie doing stuff like writing applications that scrapes metrics and show how green the energi grids are realtime, doing real time stuff around planes current climate effect given the amount of planes up in the air etc.
If thats not an option just vote with climate in mind and engage in public discussion around these issues would probably have a lot more potential
It's almost weird it haven't gotten more attention yet! Awesome post ^^
I do agree though that the most important part of a professional life is to fill the gap within your team. But that's another discussion.
On another note, how amazing it is to define our systems so we can more systematically iterate on them and improve. I love it when developers get integrated into the process as well.
The general consensus where i work is that everyone does DevOps, you develop the app, you make sure you deliver the app, if there's any issues you debug. You ain't done until your ticket is in production, and you can't point to other to solve it for you, only help you.
Where does the DevOps engineer fit in there?
What's DevOps skills in your opinion?
The analogy with agile is pretty good here. Sure you could have an Agile Engineer, that works primarily with making sure the agile process is actually used and help facilitating that. Normally that would not be a position itself though, especially not an engineering one.
Those who can manage to surpass that though can get great productivity from it though.
DevOps is great, but it's not a title. It's beautifully summarized in "The DevOps Handbook" and it's fictional counterpart "The Pheonix Project". It's about culture.
Some people might feel different and want to re-evaluate due to so many company adapting it in a similar vein many companies want to adapt agile. But make no mistake, you can't define it then, since then the context of the company defines the word. Thus sadly the word is slowly loosing its meaning.
This is likely due to lots of management people wanting to adapt the buzzword without understanding it. This since it has have had such a great success in many companies that actually know what it is, have taken the DevOps culture to heart and implemented processes in line with it.
>To each is own: I care about well tested, usability, and depending on the intended use, performance. I also care a lot about proper exhaustive documentation, which is missing from your list and from most programming languages projects.
~But I don't give a damn about its design and architecture, what matters to me is the external features, not the internals. Language designers care way too much about the internals and neglect the outside, which is what matters to the end user. I don't care if it make your parser more complicated, it if makes your grammar irregular, if you need more passes, if you need to dirty your hands with context; I want that source code using your language flows, for writing and for reading.
I think there's a disconnect here between good design and architecture and the result of it. You can't by definition have a good design and architecture that makes your program difficult to use and illogical externally. You can't have good tests without a good design and architecture. Good design and architecture goes hand in hand with usability too.
To go into a deep dive is beyond the scope here. But concisely said, good designs and architectures makes the software easy to understand and easy to change to external changes of requirements. Since its easy to reason about it's also easy to understand and reason about bugs when they inevitably shows up. If the software does not have these features, it does not have a good designs and architecture. You might think a certain architect cares more about the internals then the external, but then the architect is bad, and should study and should step back a step and think about the end user and heading of the software project. Or perhaps there's a communication issue going on, human <-> human style.
Good designs and architectures also is the equivalent, actually superior to, having good documentation. Documentation that defines the external goals are not required if you have good tests that shows them. Hell documentation about the code is not needed if the design and architecture is good. And the self documenting code can never lie. Is it difficult to achieve? Yes. But not trying will put you into a corner you can't get out of and inevitably lead to the rewrite-from-scratch. Unless of course you have a very strictly defined end goal and complete definition of done, but you could still paint yourself into a very difficult corner to get out of.
>Community? I don't really care, and I have seen it being detrimental to many projects, which lose their compass by wanting to incorporate every feature request and following the mood of the year; I'd rather they were developed between closed doors and only published when they reach beta status, to maintain consistency, instead of jumping from an unpolished feature to the next. I am aware that's totally against the current trend, where people publish repositories with a README.md before writing the first line of code or documentation :-)
Not sure i see the correlation between pushing readmes with intent and publishing unfinished feature upon unfinished feature. Isn't readme:s infact documentation? Well well :p i believe you can work in the open without jumping to unfinished feature to unfinished feature. Polish can come in the middle of a development cycle, not just the end. A vibrant community around a software also is equivalent with many contributors etc, which makes the software resilient to people moving to other things etc.
I might have sounded critical, but enjoyed reading your response. Thank you for your response :) I also believe you gave me clues to why the "written in" header is so popular.
The way you interpret certain values i gave was also insightful. I certainly don't have the same opinions, but non the less i can see where you come from. So i just had to respond to it :) Thank you!
Call me crazy, but how does the language you do this in become relevant? As a reference perhaps? Only the best of intentions here, have i missed a paticular pov that makes this extra relevant?
As always the key is getting the information to the right people at the right time, and making it more difficult to make the wrong choices then the right choices.
Rather what seem to be the issue is what security by obscurity actually means and can be missinterpreted as.
Layering lots of obscurity and putting time on that when it can be spent to increase security in the actual weakpoints or/and hiding them for developers/maintainers are problematic to say the least.
Wanna underline here that system tests are slow, unit tests are fast.
This said, i agre that you should throw away tests in a similar fashion as you do code. When it does not make sense don't be afraid to throw it, but have enough left to define the function of the code, in a documenting way. Let the code /tests speak! :D
(I literally only read the first two sentences)