23 ms·

Best practices can slow your application down

215 points by nsoonhui 5y ago

pkrumins 5y ago
The only best practice is getting your code to production as fast as possible. Code in production is worth all best practices combined.
2OEH8eoCRo0 5y ago
I'd love to know what "best practices" are.
desktopninja 5y ago
Best practices that get published/advocated are like gym memberships. works for some but not everyone. What does work though is knowing a team's culture (strengths/weaknesses) and tweaking that. It goes without saying that a best practice in one team at e.g Google will, with a high degree of certainty, fail at Amazon. Why you ask, simple ... tribalism.
Spivak 5y ago
The way I’ve dealt with this kinda of stuff and still make the day to day development experience not deteriorate is to spend the upfront time deigning good self-contained non-leaky abstractions and then hiding all your rule-breaking code behind them. I’ve used the *-able pattern with pretty good success. Let your devs mark functions as retryable, cacheable, etc. and then centralize the code that manages the caches and retry logic.
kjgkjhfkjf 5y ago
It's one thing to have a poor-quality code base. It's another thing to be proud of it, to the extent that you boast about your highly questionable decision-making in a blog post. I don't envy anyone who joins this company and has to deal with it.
- bvisness 5y ago
  SO has been wildly successful, the site is consistently fast and reliable, and it doesn't seem like their decisions have significantly held them back during development. None of this sounds "poor-quality" to me.
- taneq 5y ago
  Woah buddy, it's OK to post that kind of opinion but you're gonna need to add some kind of supporting evidence.
- commandlinefan 5y ago
  I'm with you. I read this and I think, "ok, well, it's StackOverflow, and they're obviously a bunch of really smart people... but they're still doing it wrong". I've been doing Java for 20 years now, almost since there was Java. I've observed that most Java developers migrate toward "everything is static (i.e. global)". In fact, the abomination that is the Spring "framework" more or less requires it. I don't believe they do it for performance reasons, I believe they do it because you don't have to think much (up front) that way, and you can just kick the can down the road.
meheleventyone 5y ago
Too many best practices in software engineering are followed as if they were immutable laws. Too many best practices in software engineering are followed to improve developers experience rather than the quality of the end result. Too many best practices in software engineering have no empirical basis.
- tcbasche 5y ago
  I feel like having automated testing though is objectively beneficial. I imagine SO make up for that by having a QA team and spend a heap of time manually testing stuff at the expense of “performance”.
  - meheleventyone 5y ago
    I agree, automated tests of all kinds do have empirical basis every time I’ve seen them used. You can literally see their value by measuring their output. There’s a lot more to the “best practices” around automated testing than just doing it though. And therein lies the rub.
  - nhinck2 5y ago
    There is a world of difference between objectively having benefits and being strictly beneficial.
  - commandlinefan 5y ago
    > I imagine SO make up for that by having a QA team Most places I've ever worked have made automated testing impossible but then gone ahead and made up for it by just never testing anything and then blaming the programmers when bugs show up in production.
- DocTomoe 5y ago
  Best practices, when blindly followed, especially without understanding, lead to cargo cult programming. Ill-understood best practice documents are an organisational code smell. Complaining about best practice, however, is itself a best practice.
- 5y ago
EdwardDiego 5y ago
It's like database schema design - denormalised schema are often faster for certain queries. But you should still run a 3NF schema until such time as you actually need that performance, because running a denormalised schema comes with additional complexity cost.
- drbw 5y ago
  As the old saying goes, "normalize until it hurts; denormalize until it works".
- matwood 5y ago
  What I've done in these cases is keep the tx database ~3NF and denormalized at some interval to a reporting database [1]. That seems to be a fairly standard way to do things up to a point. [1] How data gets to the reporting database is implementation specific. Simplest case is run a nightly job to copy the data over. More complex cases use things like data lakes and/or event buses where all interested parties subscribe to data they want. I'm sure there are many others.
qwertyuiop12 5y ago
If you have a qa team, perfect. But I don’t recommend to follow this way. Many code is slow due to it has a couple of wrong implementations, such as rendering or make something heavy all the time when you have to do it only one time. There is no problem to create a decoupled system using di, the final performance it will be tolerable. Also, you have the possibility to create custom builds with tests and good practices in the main branch.
- bcrosby95 5y ago
  DI is the biggest snake oil out there. The vast majority of time it's just used as a hack job to enable test isolation in weak languages and gives you no real-world decoupling. Sure it's sometimes necessary, but I wish people would stop with the expostfacto justification. It doesn't make your code better if you add it just to test your code.
  - porker 5y ago
    > DI is the biggest snake oil out there. The vast majority of time it's just used as a hack job to enable test isolation in weak languages and gives you no real-world decoupling. Have you got any data or writings to back this up? I ask because what you write is my gut feeling but I can't put it into words or convince anyone. That I have ended up programming in an area where the answer to testing is "spin that into its own class so it's testable" when the code is used in a single place, would be fine as a private or protected method, but still needs tests to confirm the output is right, drives me crazy. For libraries sure, but for checking the date parsing is right, that you didn't mess up the calculation... just let me test the damn protected method and be done with it. Hundreds of tiny classes benefits no one, only the testing framework.
  - ivanche 5y ago
    I'm interested in your proposal for an alternative. Service Locator? New operator everywhere, used at-will? Something else?
    - selfhoster11 5y ago
criticaltinker 5y ago
> But it’s no silver bullet: your software is not going to crash and burn if you don’t write your tests first, and the presence of tests alone does not mean you won’t have maintainability issues. > It was not our priority early on. Now that we have had a product up and running successfully for many years, it’s time to pay more attention to it. This is a hard earned lesson but one that is firmly rooted in the reality of the industry IMO. I’ve had the good fortune of working on a few greenfield products and bringing them to market. Time and time again I see technical and executive leadership steer teams in this direction. The fact is that writing good tests is hard and expensive. And most new software products survive less than a handful of years. Accepting this reality will help ease the pain of working on that spaghetti codebase at your day job. At least it did for me. Good on stackoverflow for paying back some tech debt in their successful product. I certainly appreciate the tradeoffs that come with building a business, but they can be difficult to swallow for engineers who take pride in producing high quality and well tested code.
- pjmlp 5y ago
  I for one am quite happy that the whole hype from pair programming, extreme programming, whatever X programming with mocking everything for 100% coverage on QA dashboards is now behind us.
tcbasche 5y ago
Has anyone actually really noticed the performance of Stack Overflow? It feels like your average website before the JS bloat took over most “forum” style sites. I wonder if they’ve traded off performance (and by the sounds of it, maintainability) with cost by squeezing all they can out of a minimal amount of hardware.
- DocTomoe 5y ago
  That's the difference between web development, "web2.0-style", and engineering. A web developer, when experiencing lag, will just add another AWS instance. An engineer will figure out where things are inefficient, and work against that inefficiency. You would be surprised how much of a performance boost you can get just by having good server-side pre-caching. Also, consider that a lot of the lag you experience in the web today is actually caused client-side by excessive use of JS.
  - tcbasche 5y ago
    Yeah I suspect your latter point is very much the case and part of my point. I guess it was an interesting tradeoff they made early on that seems to have paid off. I just wonder what the development experience is like…
  - bee_rider 5y ago
    Engineering is a pretty slow-and-steady profession. Best practices, tests, and robustness are part of the point. There's an argument that a good engineer would know when those criteria are satisfied and so be more able to run up to the cusp, but I don't think it is fair to say engineers necessarily (or typically) work against inefficiency. Adding more AWS nodes might be the boring, prudent choice. Redundancy is a form of inefficiency. Failure paths often introduce inefficiency. Well defined tolerances introduce inefficiency... even though you know those motors could handle a couple extra volts...
- selfhoster11 5y ago
  I've never had issues with SO, and I'm usually sensitive to websites being annoyingly slow.
yongjik 5y ago
Before anyone wants to criticize Stack Overflow, consider their server footprints as of 2016 [1]: 4 Microsoft SQL Servers (new hardware for 2 of them) 11 IIS Web Servers (new hardware) 2 Redis Servers (new hardware) 3 Tag Engine servers (new hardware for 2 of the 3) 3 Elasticsearch servers (same) 4 HAProxy Load Balancers (added 2 to support CloudFlare) 2 Networks (each a Nexus 5596 Core + 2232TM Fabric Extenders, upgraded to 10Gbps everywhere) 2 Fortinet 800C Firewalls (replaced Cisco 5525-X ASAs) 2 Cisco ASR-1001 Routers (replaced Cisco 3945 Routers) 2 Cisco ASR-1001-x Routers (new!) Assuming they aren't lying, this is the entire list of machines needed for a site used by the world's developers. That's no small feat. Many companies whose developers blog about their "best practices" would struggle to achieve 1/10th as much efficiency. [1] https://nickcraver.com/blog/2016/02/17/stack-overflow-the-architecture-2016-edition/ https://nickcraver.com/blog/2016/02/17/stack-overflow-the-ar...
- kjgkjhfkjf 5y ago
  If they'd used open-source software rather than the Microsoft stack, they could have scaled horizontally without having to worry about buying more software licenses.
  - mrweasel 5y ago
    Personally I'd rather manage a small number of large servers, compared to managing a large number of smaller ones. The licensing costs associated with Stack Overflow also can't been that large. Sure Microsoft software isn't cheap, but it's also not that expensive. The licensing cost is easily offset by staying on a technology stack their employees know.
    - kjgkjhfkjf 5y ago
      > The licensing cost is easily offset by staying on a technology stack their employees know. Stack Overflow wasn't developed by an established software company. It was a completely new startup, founded by two high-profile (at the time) software commentators. They could have hired people to use any stack they wanted. While the state of web development wasn't what it is today, OSS stacks such as the LAMP stack were fairly well-understood and popular.
throw8932894 5y ago
Back in 2005 Ebay was served using single executable binary that had around 100MB. At some point they hit maximal number of functions allowed by compiler. Back than the best "practice" for large scale services was enterprise Java on VERY expensive Sun server.
- commandlinefan 5y ago
  > single executable binary that had around 100MB I read that and I feel a surge of sympathy for the new guy they hired to work on this thing. How many MONTHS did it take him to even compile it? How many hours of frustration did he have to spend thinking, "I can't even get this thing to build, they're gonna fire me, I need this job or my kids are gonna starve..."
  - gmfawcett 5y ago
    If you have only one artifact in your build process, you can afford the time to document the build process. :)
0x0nyandesu 5y ago
Completely accurate assessment.
urban_winter 5y ago
An obvious question is whether the focus on performance first is correlated with the success of stack overflow. If the same level of succes could have been achieved without squeezing as much performance out of each server then the sacrifice of testability is a dubious one. The article doesn't explain why horizontal scalability wasn't pursued instead of their approach of performance efficiency (i.e. greater performance from a given amount of resource). It's certainly true that at the time that SO was starting, scaling horizontally required far more handbuilt tooling than it does today but it certainly was already a widely used pattern. The likely reason is cost, but that then comes back to the first question - would SO have been equally successful if it had higher infrastructure costs in its early days? The persuit of efficient performance at the cost of aspects of quality (of which testability is only one) can only be justified if efficient performance is truly necessary for success. A much smarter person than me warned against premature optimisation. That seems relevant here.
- kjgkjhfkjf 5y ago
  They use the Microsoft stack, so they'd have to buy more licenses if they scaled horizontally. Yes, it raised quite a few eyebrows when they announced this decision.
  - tomnipotent 5y ago
    > it raised quite a few eyebrows No it didn't, except for people that seem to raise eyebrows regardless of what they read.
  - simonjgreen 5y ago
    If you understand Microsoft licensing well you'll know it also costs to scale vertically. Depending on your license procurement model (SPLA, Retail, OEM, OVA) you are usually paying for server software on a per-cores basis. Some products (included most mentioned) have a scale tipping point where they become more flexible (DC licensing).
    - sofixa 5y ago
DeathArrow 5y ago
>Best practices can slow your application down Yes, but they will do it in an elegant manner and be sanctioned by lots of self appointed experts. Where would us be today without the wisdom of Uncle Bob and Gang of Four? We would be still in the prehistory of programming writing efficient, inelegant code.
- danuker 5y ago
  It depends on the application. You have to balance the costs of writing efficient code with the costs of running the machines. If you have lots of users hitting your servers, it's worth investing more in efficiency, but if you barely have any, it's much more worth it to write in a convention focusing on maintainability.
- kaba0 5y ago
  There are entirely different problem domains inside software engineering. Pushing that last bit of performance at the price of some maintainability can be the sane choice for some numerical optimization/simulation algorithm for example, but would be a terrible choice for a bank application dealing with transactions and having often changing requirements. At the latter, even serious inefficiencies are absolutely worth it. Hardware is relatively cheap and really fast. Also, don’t forget that we are trying to balance at the top of the often non-reducable complexity mountains, never ever seen before. Compared to some of the programs out there, going to the moon is just some trivial computations. The former may very well not be remotely possible without some structure for our limited human brains.
ajuc 5y ago
In my current job we have "best practice" to use optionals instead of if (x != null). It makes code like 5 times slower. We are still required to do this. It's absurd.
- LammyL 5y ago
  Is that slowness actually measurable/noticeable or is it just theoretical?
- tester756 5y ago
  0.0001 * 5 is still 0.0005
idontwantthis 5y ago
From the comments in 2021: > Perhaps we were not super clear in that piece – but testing is one of the things we “punted” back then and are definitely fixing now. One of our major engineering goals in the past few years was writing comprehensive test suites – and all new features are getting their share of automated tests as well. We still have way more integration tests than unit tests, but our test coverage is increasing progressively.
deanCommie 5y ago
The comments here are all discussing the ideas presented abstractly. I'm more interested in the specifics: > We use a lot of static methods and fields as to minimize allocations whenever we have to. By minimizing allocations and making the memory footprint as slim as possible, we decrease the application stalls due to garbage collection. I would really love to see some profiling comparisons on this. I simply cannot believe that just avoiding object initialization or state would add up to a meaningful difference. Any reasonable inversion of control framework applied dogmatically would pretty much ensure you almost never initialize objects at runtime anyway - only at service startup. BUT you maintain the clean composition and encapsulation of objects and gain the testability that they've given up. I also can't believe that using fields directly over (i assume) Properties would make a meaningful difference either... Again, not doubting the premise that if job one is performance that you have to make readability and maintainability compromises. But I am unsure if the examples presented here are actually relevant, or were they just easy to digest in a blog post. My guess? They operated in crunch-y startup mode for many years, optimized feature delivery over all else (appropriate), and now have a messy kludgy codebase that - at least - remains performant. Now they're scared to refactor it and improve it list the performance gods smile unkindly, and have come up with ipso-facto justifications for why they don't want to bother with writing unit tests (which incidentally work JUST FINE with unit testing static methods)
- tester756 5y ago
  Just google: `.NET performance improvements` and you'll have a few blog posts full of avoiding allocating stuff and how significant difference it made over years
- ajuc 5y ago
  > I simply cannot believe that just avoiding object initialization or state would add up to a meaningful difference. Depends in how tight a loop you do it. If you do a lot of stuff and once in a blue moon you do this - fine. If you create and destroy objects every time you do basic operation that most of your code consists of - you'll be several times slower. In my current job we are required to do this: Optional.of(user).ifPresent(this::doSomethingWithUser); instead of this: if (user != null) { doSomethingWithUser(user); } The code is very simple and mostly consist of taking json, parsing it, checking a few fields and modifying them, and calling another service with another format of json. Most of what we do is these null checks disguised as opionals. And then people complain performance got worse compared to mainframe assembler.
civilized 5y ago
Hmm.... if certain practices do not achieve the "best" "practical" outcome, were they ever truly "best practices"?
_xnmw 5y ago
There is a big difference between developers who know their hardware stack, and those who don't. Performance efficiency is often an order of magnitude out of whack for companies that prefer a horizontal-first scaling approach (i.e. lots of containers in the cloud, k8s, etc.). As an extreme example, consider Plaid, which at one point had 4000 Node containers [1] running in parallel to handle just as many requests per second. My guess is they could've easily done with a few beefy baremetal machines, if they knew their hardware well, and architected it sensibly from the beginning. Money wasn't a problem for them because they were able to just throw $350k a year at AWS to make it work (and millions more at their dev team). But money isn't the only thing. This sort of approach sacrifices real-time latency (which is felt by the user), reliability (Plaid is notorious for having a ~20% fail rate for requests), flexibility (Plaid is notoriously slow at fixing bugs), developer costs (a dedicated DevOps team), agility (very slow deployment times), not to mention the priceless value of simplicity, a system that can fit in the mind of a single experienced developer, so they can write and test performant code on their own machine. But hey, Plaid is now a unicorn, so who cares about efficiency. [1] https://plaid.com/blog/how-we-parallelized-our-node-service-by-30x/ https://plaid.com/blog/how-we-parallelized-our-node-service-...
- p_l 5y ago
  Funnily enough, k8s thrives the best when hw is your constraint, in my opinion...
  - marcos100 5y ago
    When you program without performance in mind, hw is always your constraint. k8s is a blessing because you can scale out easily and is a curse because you can scale out easily.
    - p_l 5y ago
      Thing is, k8s is not about scaling out. A core part of it is about efficient usage of hw you have (which also maps well to avoid expensive cloud bill). The more I optimized, the more I could leverage k8s to optimize hw usage.
pictur 5y ago
Any system that you don't know how it really works end-to-end is doomed to slow down.
jve 5y ago
> Similarly, we don’t write unit tests for every new feature. The thing that hinders our ability to unit test is precisely the focus on static structures. Static methods and properties are global, harder to replace at runtime, and therefore, harder to “stub” or “mock.” Those capabilities are very important for proper isolated unit testing. If we cannot mock a database connection, for instance, we cannot write tests that don’t have access to the database. With our code base, you won’t be able to easily do test driven development or similar practices that the industry seems to love. Why bother with stubbing, mocking and changing code to be testable if you can use the more useful integration and/or UI tests? They will bring in some great value without having to rearchitect code.
- adwn 5y ago
  Because fine-grained tests allow for more complete coverage of complex but tightly-bounded code sections. For example, if you've implemented a concurrent data structure, it's much easier to verify its correctness with unit tests; with integration tests only, it would be a lot more effort and more difficult, maybe even impossible, to thoroughly test all code paths. Of course, if your entire software only consists of trivial glue code, then don't bother with unit tests, I guess.
  - marcosdumay 5y ago
    Odds are that the concurrent data structure will naturally be very testable. If it's not, it a matter of abstracting it a bit more, not of using the testability design guidebook. But well, mocks and stubs is how you test the thing, and has no relation to coding best practices. I think the GP had an unreasonable grouping here.
- commandlinefan 5y ago
  > Why bother with stubbing, mocking and changing code to be testable if you can use the more useful integration End-to-end tests are useful, but they take a long time to set up, maintain and run. They have to have a live database to connect to and that database itself has to conform to particular preconditions that can easily be violated even if the code itself is just fine. What I've seen, over and over, is that the end-to-end test fail because the test database instance is under load, or somebody wrote a test that inserted some data but forgot to remove it, or it doesn't work right if two particular tests run at the same time, to the point where they report false negatives so often, everybody just starts ignoring them.
tored 5y ago
Even if you have written your application in a specific manner to achieve some technical goal, for Stack Overflow that is performance, you can still have automated testing with end-to-end test or system tests. I prefer that over unit tests because a test that is larger in scale does not care how you have organized your code in contrast to a unit test. Thus you can refactor all you want and the tests stays the same. Unit tests on the other hand becomes useless when doing large refactoring because you have to throw them out or refactor them too when classes and/or functions get removed or changed.
- DerArzt 5y ago
  To add to this, The whole TDD approach as described in the original book by Kent Beck advocated for throwing away your smaller unit tests after a certain point while keeping the higher level ones. This way you can still be confident in your code on the local level, but you won't get bogged down in the future when you need to do foundational changes. Sometimes I get the feeling that the TDD cargo cult members haven't read the original material.
hsn915 5y ago
It's simply impossible to have reliable "best practices" in programming. It's still a young field and most of the ideas floating around are just fads. Yesterday's best practice will quickly become an anti-pattern tomorrow when another person comes along and creates a pretty looking website to promote his best practice. None of it is based on actual collective experience. Just the opinions of people who are good at marketing their ideas. Somehow if something is nicely written up and put up on a good looking website, everyone starts treating it like a well accepted best practice. Examples that come to mind: https://www.conventionalcommits.org/ https://www.conventionalcommits.org/ https://nvie.com/posts/a-successful-git-branching-model/ https://nvie.com/posts/a-successful-git-branching-model/ https://semver.org/ https://semver.org/
- marginalia_nu 5y ago
  > None of it is based on actual collective experience. Just the opinions of people who are good at marketing their ideas. I think often best practices are based on experience, but they stem from a lost programming zeitgeist that the new practices have replaced. Before Don't Repeat Yourself became popular, there was a serious problem with code duplication. Now there is a serious phobia of code duplication instead (to the point where it's a problem). DRY was good advice in a world where DRY was an obscure idea, is bad advice in a world where DRY is a popular idea. If you look at something like Clean Code today, it seems like a bunch of pretty bad advice, but in the context of the late 2000s Enterprise Java, it seemed like a really fresh breeze. We've already adopted the good ideas, and discovered that pushing farther in that direction was a bad idea. These books and ideas were lauded for a reason, but often that reason isn't there anymore.
  - hsn915 5y ago
    > > None of it is based on actual collective experience > I think often best practices are based on experience But not collective experience. Just some people's experience. If you survey experienced people in different corners of the industry, you will not find agreement with whatever is currently being floated as a best practice. Rather amusingly, best practices are often adopted much more strongly by the beginners (and the expert[0] beginners) rather than the experienced. When you reach intermediate level of experience you start questioning many of what you learned from the internet as a best practice and start looking for alternatives or just experimenting yourself with different ways of doing things. [0]: By "expert" beginners, I mean people who got stuck in a rut. See: https://daedtech.com/how-developers-stop-learning-rise-of-the-expert-beginner/ https://daedtech.com/how-developers-stop-learning-rise-of-th... But beginners will always out number the experienced, and they form an echo chamber. This is because every year, many beginners join, but reaching an adequate level of experience to start questioning the crowd wisdom takes several years. By the time you get out of the rut of "best practices", you are in the minority. Imagine a pryamid and you're in the middle of it. There's a lot more volume below you than above you. > If you look at something like Clean Code today, it seems like a bunch of pretty bad advice, but in the context of the late 2000s Enterprise Java, it seemed like a really fresh breeze. We've already adopted the good ideas, and discovered that pushing farther in that direction was a bad idea. I kindly disagree. I think people get better with experience. Maybe a long the way you encounter many different opinions and you try out different things. But I can't say that the particularly bad advice was useful for you in your journey to improve your skills. Quite the opposite, they might have been a hinderence, and maybe you would have grown a lot faster if you were lucky enough to not have encountered them. I have no idea what Enterprise Java was like a decade ago, but I can't imagine it was much worse or better than it is now. I can't say I have ever seen a Java code base that I thought positively of. They might be terrible in different ways, but all terrible none the less.
fassssst 5y ago
“ Similarly, we don’t write unit tests for every new feature. The thing that hinders our ability to unit test is precisely the focus on static structures. Static methods and properties are global, harder to replace at runtime, and therefore, harder to “stub” or “mock.” Those capabilities are very important for proper isolated unit testing.” Is it in C#? That’s surprising. It’s relatively easy to stub and mock things out in C++, so you don’t need all these “testability” patterns, although I do find passing dependencies around as constructor parameters or properties makes code easier to understand overall.
- treis 5y ago
  I think they're point is that parameter passing is a performance hit they wanted to avoid. But it didn't make sense to me either. I don't know anything about C# but I assume there's some way to use compile time flags to assign static values. Seems like they should be able to mock that way.
lkrubner 5y ago
Regarding the basic idea that "best practices are not always best" I've been involved in a lot of these conversations at small startups, and mostly around technologies like Kubernetes. But every time I say something critical about Kubernetes, someone responds, "So you think Google is stupid? You think the engineers at Google don't know what they're doing?" To which I always respond: "Are you Google? Are you running 10 million boxes at 50 data centers in 30 countries? If not, you might consider a simpler approach." I do get that big companies find something like Docker/Kubernetes useful for security, scaling, and especially, dealing with the homogenous nature of the varied software stacks that typically build up in a large corporation. However, my message to the small startups I consult with is, "Keep it simple. If possible, just stick with something like Heroku for awhile, or a few big, beefy machines. You don't need High Availability, you can survive with 99.99% uptime for now. You've got an engineering team of 3 people, so keep everything simple." And yet I still get some pushback, people saying, "No, we want play in the big leagues, we want everything to be perfect right from the start." That kind of perfectionism can kill a startup. That kind of perfectionism is entirely at odds with the spirit of a "minimal viable product." Yet I keep having clients who want to prematurely imitate the best practices of Google, long before they have revenue to justify it. I wrote a satire of how some of these conversations go, which I posted here: http://www.smashcompany.com/technology/my-final-post-regarding-the-flaws-of-docker-kubernetes-and-their-eco-system http://www.smashcompany.com/technology/my-final-post-regardi...
- maccard 5y ago
  I work for a startup and we use k8s for our web service deployments for two reasons - there is ample material available, and there are hosted services available. As we've grown its been helpful to be able to utilise all of the ecosystem around k8s. It's been a huge kick-start for our team.
ineedasername 5y ago
I think it's fair to say that best practices are specific to goals. Low latency, overall load time, ease of scale... These will all have different (though perhaps overlapping) best practices. The trick, as with most projects, is balancing goals against methods.
csbartus 5y ago
This is a very misleading title aka clickbait. It might be true for a domain, and false in another. Yet it sounds like a general rule. For example, in my development environment, this is not true. Best practices - collected and distilled during years - are stuffed into code generators which generate skeleton code across projects and teams. They don't slow the app down, and increase app development speed with orders of magnitude.

215 points by nsoonhui 5y ago

The only best practice is getting your code to production as fast as possible. Code in production is worth all best practices combined.

2OEH8eoCRo0 5y ago

I'd love to know what "best practices" are.

desktopninja 5y ago

Best practices that get published/advocated are like gym memberships. works for some but not everyone. What does work though is knowing a team's culture (strengths/weaknesses) and tweaking that. It goes without saying that a best practice in one team at e.g Google will, with a high degree of certainty, fail at Amazon. Why you ask, simple ... tribalism.

Spivak 5y ago

The way I’ve dealt with this kinda of stuff and still make the day to day development experience not deteriorate is to spend the upfront time deigning good self-contained non-leaky abstractions and then hiding all your rule-breaking code behind them. I’ve used the *-able pattern with pretty good success. Let your devs mark functions as retryable, cacheable, etc. and then centralize the code that manages the caches and retry logic.

kjgkjhfkjf 5y ago

It's one thing to have a poor-quality code base. It's another thing to be proud of it, to the extent that you boast about your highly questionable decision-making in a blog post. I don't envy anyone who joins this company and has to deal with it.

bvisness 5y ago
SO has been wildly successful, the site is consistently fast and reliable, and it doesn't seem like their decisions have significantly held them back during development. None of this sounds "poor-quality" to me.
taneq 5y ago
Woah buddy, it's OK to post that kind of opinion but you're gonna need to add some kind of supporting evidence.
commandlinefan 5y ago
I'm with you. I read this and I think, "ok, well, it's StackOverflow, and they're obviously a bunch of really smart people... but they're still doing it wrong". I've been doing Java for 20 years now, almost since there was Java. I've observed that most Java developers migrate toward "everything is static (i.e. global)". In fact, the abomination that is the Spring "framework" more or less requires it. I don't believe they do it for performance reasons, I believe they do it because you don't have to think much (up front) that way, and you can just kick the can down the road.

meheleventyone 5y ago

Too many best practices in software engineering are followed as if they were immutable laws. Too many best practices in software engineering are followed to improve developers experience rather than the quality of the end result. Too many best practices in software engineering have no empirical basis.

tcbasche 5y ago
I feel like having automated testing though is objectively beneficial. I imagine SO make up for that by having a QA team and spend a heap of time manually testing stuff at the expense of “performance”.
- meheleventyone 5y ago
  I agree, automated tests of all kinds do have empirical basis every time I’ve seen them used. You can literally see their value by measuring their output. There’s a lot more to the “best practices” around automated testing than just doing it though. And therein lies the rub.
- nhinck2 5y ago
  There is a world of difference between objectively having benefits and being strictly beneficial.
- commandlinefan 5y ago
  > I imagine SO make up for that by having a QA team Most places I've ever worked have made automated testing impossible but then gone ahead and made up for it by just never testing anything and then blaming the programmers when bugs show up in production.
DocTomoe 5y ago
Best practices, when blindly followed, especially without understanding, lead to cargo cult programming. Ill-understood best practice documents are an organisational code smell. Complaining about best practice, however, is itself a best practice.
5y ago

EdwardDiego 5y ago

It's like database schema design - denormalised schema are often faster for certain queries. But you should still run a 3NF schema until such time as you actually need that performance, because running a denormalised schema comes with additional complexity cost.

drbw 5y ago
As the old saying goes, "normalize until it hurts; denormalize until it works".
matwood 5y ago
What I've done in these cases is keep the tx database ~3NF and denormalized at some interval to a reporting database [1]. That seems to be a fairly standard way to do things up to a point. [1] How data gets to the reporting database is implementation specific. Simplest case is run a nightly job to copy the data over. More complex cases use things like data lakes and/or event buses where all interested parties subscribe to data they want. I'm sure there are many others.

qwertyuiop12 5y ago

If you have a qa team, perfect. But I don’t recommend to follow this way. Many code is slow due to it has a couple of wrong implementations, such as rendering or make something heavy all the time when you have to do it only one time. There is no problem to create a decoupled system using di, the final performance it will be tolerable. Also, you have the possibility to create custom builds with tests and good practices in the main branch.

bcrosby95 5y ago
DI is the biggest snake oil out there. The vast majority of time it's just used as a hack job to enable test isolation in weak languages and gives you no real-world decoupling. Sure it's sometimes necessary, but I wish people would stop with the expostfacto justification. It doesn't make your code better if you add it just to test your code.
- porker 5y ago
  > DI is the biggest snake oil out there. The vast majority of time it's just used as a hack job to enable test isolation in weak languages and gives you no real-world decoupling. Have you got any data or writings to back this up? I ask because what you write is my gut feeling but I can't put it into words or convince anyone. That I have ended up programming in an area where the answer to testing is "spin that into its own class so it's testable" when the code is used in a single place, would be fine as a private or protected method, but still needs tests to confirm the output is right, drives me crazy. For libraries sure, but for checking the date parsing is right, that you didn't mess up the calculation... just let me test the damn protected method and be done with it. Hundreds of tiny classes benefits no one, only the testing framework.
- ivanche 5y ago
  I'm interested in your proposal for an alternative. Service Locator? New operator everywhere, used at-will? Something else?
  - selfhoster11 5y ago

criticaltinker 5y ago

> But it’s no silver bullet: your software is not going to crash and burn if you don’t write your tests first, and the presence of tests alone does not mean you won’t have maintainability issues. > It was not our priority early on. Now that we have had a product up and running successfully for many years, it’s time to pay more attention to it. This is a hard earned lesson but one that is firmly rooted in the reality of the industry IMO. I’ve had the good fortune of working on a few greenfield products and bringing them to market. Time and time again I see technical and executive leadership steer teams in this direction. The fact is that writing good tests is hard and expensive. And most new software products survive less than a handful of years. Accepting this reality will help ease the pain of working on that spaghetti codebase at your day job. At least it did for me. Good on stackoverflow for paying back some tech debt in their successful product. I certainly appreciate the tradeoffs that come with building a business, but they can be difficult to swallow for engineers who take pride in producing high quality and well tested code.

pjmlp 5y ago
I for one am quite happy that the whole hype from pair programming, extreme programming, whatever X programming with mocking everything for 100% coverage on QA dashboards is now behind us.

tcbasche 5y ago

Has anyone actually really noticed the performance of Stack Overflow? It feels like your average website before the JS bloat took over most “forum” style sites. I wonder if they’ve traded off performance (and by the sounds of it, maintainability) with cost by squeezing all they can out of a minimal amount of hardware.

DocTomoe 5y ago
That's the difference between web development, "web2.0-style", and engineering. A web developer, when experiencing lag, will just add another AWS instance. An engineer will figure out where things are inefficient, and work against that inefficiency. You would be surprised how much of a performance boost you can get just by having good server-side pre-caching. Also, consider that a lot of the lag you experience in the web today is actually caused client-side by excessive use of JS.
- tcbasche 5y ago
  Yeah I suspect your latter point is very much the case and part of my point. I guess it was an interesting tradeoff they made early on that seems to have paid off. I just wonder what the development experience is like…
- bee_rider 5y ago
  Engineering is a pretty slow-and-steady profession. Best practices, tests, and robustness are part of the point. There's an argument that a good engineer would know when those criteria are satisfied and so be more able to run up to the cusp, but I don't think it is fair to say engineers necessarily (or typically) work against inefficiency. Adding more AWS nodes might be the boring, prudent choice. Redundancy is a form of inefficiency. Failure paths often introduce inefficiency. Well defined tolerances introduce inefficiency... even though you know those motors could handle a couple extra volts...
selfhoster11 5y ago
I've never had issues with SO, and I'm usually sensitive to websites being annoyingly slow.

yongjik 5y ago

Before anyone wants to criticize Stack Overflow, consider their server footprints as of 2016 [1]: 4 Microsoft SQL Servers (new hardware for 2 of them) 11 IIS Web Servers (new hardware) 2 Redis Servers (new hardware) 3 Tag Engine servers (new hardware for 2 of the 3) 3 Elasticsearch servers (same) 4 HAProxy Load Balancers (added 2 to support CloudFlare) 2 Networks (each a Nexus 5596 Core + 2232TM Fabric Extenders, upgraded to 10Gbps everywhere) 2 Fortinet 800C Firewalls (replaced Cisco 5525-X ASAs) 2 Cisco ASR-1001 Routers (replaced Cisco 3945 Routers) 2 Cisco ASR-1001-x Routers (new!) Assuming they aren't lying, this is the entire list of machines needed for a site used by the world's developers. That's no small feat. Many companies whose developers blog about their "best practices" would struggle to achieve 1/10th as much efficiency. [1] https://nickcraver.com/blog/2016/02/17/stack-overflow-the-architecture-2016-edition/ https://nickcraver.com/blog/2016/02/17/stack-overflow-the-ar...

kjgkjhfkjf 5y ago
If they'd used open-source software rather than the Microsoft stack, they could have scaled horizontally without having to worry about buying more software licenses.
- mrweasel 5y ago
  Personally I'd rather manage a small number of large servers, compared to managing a large number of smaller ones. The licensing costs associated with Stack Overflow also can't been that large. Sure Microsoft software isn't cheap, but it's also not that expensive. The licensing cost is easily offset by staying on a technology stack their employees know.
  - kjgkjhfkjf 5y ago
    > The licensing cost is easily offset by staying on a technology stack their employees know. Stack Overflow wasn't developed by an established software company. It was a completely new startup, founded by two high-profile (at the time) software commentators. They could have hired people to use any stack they wanted. While the state of web development wasn't what it is today, OSS stacks such as the LAMP stack were fairly well-understood and popular.

throw8932894 5y ago

Back in 2005 Ebay was served using single executable binary that had around 100MB. At some point they hit maximal number of functions allowed by compiler. Back than the best "practice" for large scale services was enterprise Java on VERY expensive Sun server.

commandlinefan 5y ago
> single executable binary that had around 100MB I read that and I feel a surge of sympathy for the new guy they hired to work on this thing. How many MONTHS did it take him to even compile it? How many hours of frustration did he have to spend thinking, "I can't even get this thing to build, they're gonna fire me, I need this job or my kids are gonna starve..."
- gmfawcett 5y ago
  If you have only one artifact in your build process, you can afford the time to document the build process. :)

0x0nyandesu 5y ago

Completely accurate assessment.

urban_winter 5y ago

An obvious question is whether the focus on performance first is correlated with the success of stack overflow. If the same level of succes could have been achieved without squeezing as much performance out of each server then the sacrifice of testability is a dubious one. The article doesn't explain why horizontal scalability wasn't pursued instead of their approach of performance efficiency (i.e. greater performance from a given amount of resource). It's certainly true that at the time that SO was starting, scaling horizontally required far more handbuilt tooling than it does today but it certainly was already a widely used pattern. The likely reason is cost, but that then comes back to the first question - would SO have been equally successful if it had higher infrastructure costs in its early days? The persuit of efficient performance at the cost of aspects of quality (of which testability is only one) can only be justified if efficient performance is truly necessary for success. A much smarter person than me warned against premature optimisation. That seems relevant here.

kjgkjhfkjf 5y ago
They use the Microsoft stack, so they'd have to buy more licenses if they scaled horizontally. Yes, it raised quite a few eyebrows when they announced this decision.
- tomnipotent 5y ago
  > it raised quite a few eyebrows No it didn't, except for people that seem to raise eyebrows regardless of what they read.
- simonjgreen 5y ago
  If you understand Microsoft licensing well you'll know it also costs to scale vertically. Depending on your license procurement model (SPLA, Retail, OEM, OVA) you are usually paying for server software on a per-cores basis. Some products (included most mentioned) have a scale tipping point where they become more flexible (DC licensing).
  - sofixa 5y ago

DeathArrow 5y ago

>Best practices can slow your application down Yes, but they will do it in an elegant manner and be sanctioned by lots of self appointed experts. Where would us be today without the wisdom of Uncle Bob and Gang of Four? We would be still in the prehistory of programming writing efficient, inelegant code.

danuker 5y ago
It depends on the application. You have to balance the costs of writing efficient code with the costs of running the machines. If you have lots of users hitting your servers, it's worth investing more in efficiency, but if you barely have any, it's much more worth it to write in a convention focusing on maintainability.
kaba0 5y ago
There are entirely different problem domains inside software engineering. Pushing that last bit of performance at the price of some maintainability can be the sane choice for some numerical optimization/simulation algorithm for example, but would be a terrible choice for a bank application dealing with transactions and having often changing requirements. At the latter, even serious inefficiencies are absolutely worth it. Hardware is relatively cheap and really fast. Also, don’t forget that we are trying to balance at the top of the often non-reducable complexity mountains, never ever seen before. Compared to some of the programs out there, going to the moon is just some trivial computations. The former may very well not be remotely possible without some structure for our limited human brains.

ajuc 5y ago

In my current job we have "best practice" to use optionals instead of if (x != null). It makes code like 5 times slower. We are still required to do this. It's absurd.

LammyL 5y ago
Is that slowness actually measurable/noticeable or is it just theoretical?
tester756 5y ago
0.0001 * 5 is still 0.0005

idontwantthis 5y ago

From the comments in 2021: > Perhaps we were not super clear in that piece – but testing is one of the things we “punted” back then and are definitely fixing now. One of our major engineering goals in the past few years was writing comprehensive test suites – and all new features are getting their share of automated tests as well. We still have way more integration tests than unit tests, but our test coverage is increasing progressively.

deanCommie 5y ago

The comments here are all discussing the ideas presented abstractly. I'm more interested in the specifics: > We use a lot of static methods and fields as to minimize allocations whenever we have to. By minimizing allocations and making the memory footprint as slim as possible, we decrease the application stalls due to garbage collection. I would really love to see some profiling comparisons on this. I simply cannot believe that just avoiding object initialization or state would add up to a meaningful difference. Any reasonable inversion of control framework applied dogmatically would pretty much ensure you almost never initialize objects at runtime anyway - only at service startup. BUT you maintain the clean composition and encapsulation of objects and gain the testability that they've given up. I also can't believe that using fields directly over (i assume) Properties would make a meaningful difference either... Again, not doubting the premise that if job one is performance that you have to make readability and maintainability compromises. But I am unsure if the examples presented here are actually relevant, or were they just easy to digest in a blog post. My guess? They operated in crunch-y startup mode for many years, optimized feature delivery over all else (appropriate), and now have a messy kludgy codebase that - at least - remains performant. Now they're scared to refactor it and improve it list the performance gods smile unkindly, and have come up with ipso-facto justifications for why they don't want to bother with writing unit tests (which incidentally work JUST FINE with unit testing static methods)

tester756 5y ago
Just google: `.NET performance improvements` and you'll have a few blog posts full of avoiding allocating stuff and how significant difference it made over years
ajuc 5y ago
> I simply cannot believe that just avoiding object initialization or state would add up to a meaningful difference. Depends in how tight a loop you do it. If you do a lot of stuff and once in a blue moon you do this - fine. If you create and destroy objects every time you do basic operation that most of your code consists of - you'll be several times slower. In my current job we are required to do this: Optional.of(user).ifPresent(this::doSomethingWithUser); instead of this: if (user != null) { doSomethingWithUser(user); } The code is very simple and mostly consist of taking json, parsing it, checking a few fields and modifying them, and calling another service with another format of json. Most of what we do is these null checks disguised as opionals. And then people complain performance got worse compared to mainframe assembler.

civilized 5y ago

Hmm.... if certain practices do not achieve the "best" "practical" outcome, were they ever truly "best practices"?

_xnmw 5y ago

There is a big difference between developers who know their hardware stack, and those who don't. Performance efficiency is often an order of magnitude out of whack for companies that prefer a horizontal-first scaling approach (i.e. lots of containers in the cloud, k8s, etc.). As an extreme example, consider Plaid, which at one point had 4000 Node containers [1] running in parallel to handle just as many requests per second. My guess is they could've easily done with a few beefy baremetal machines, if they knew their hardware well, and architected it sensibly from the beginning. Money wasn't a problem for them because they were able to just throw $350k a year at AWS to make it work (and millions more at their dev team). But money isn't the only thing. This sort of approach sacrifices real-time latency (which is felt by the user), reliability (Plaid is notorious for having a ~20% fail rate for requests), flexibility (Plaid is notoriously slow at fixing bugs), developer costs (a dedicated DevOps team), agility (very slow deployment times), not to mention the priceless value of simplicity, a system that can fit in the mind of a single experienced developer, so they can write and test performant code on their own machine. But hey, Plaid is now a unicorn, so who cares about efficiency. [1] https://plaid.com/blog/how-we-parallelized-our-node-service-by-30x/ https://plaid.com/blog/how-we-parallelized-our-node-service-...

p_l 5y ago
Funnily enough, k8s thrives the best when hw is your constraint, in my opinion...
- marcos100 5y ago
  When you program without performance in mind, hw is always your constraint. k8s is a blessing because you can scale out easily and is a curse because you can scale out easily.
  - p_l 5y ago
    Thing is, k8s is not about scaling out. A core part of it is about efficient usage of hw you have (which also maps well to avoid expensive cloud bill). The more I optimized, the more I could leverage k8s to optimize hw usage.

pictur 5y ago

Any system that you don't know how it really works end-to-end is doomed to slow down.

jve 5y ago

> Similarly, we don’t write unit tests for every new feature. The thing that hinders our ability to unit test is precisely the focus on static structures. Static methods and properties are global, harder to replace at runtime, and therefore, harder to “stub” or “mock.” Those capabilities are very important for proper isolated unit testing. If we cannot mock a database connection, for instance, we cannot write tests that don’t have access to the database. With our code base, you won’t be able to easily do test driven development or similar practices that the industry seems to love. Why bother with stubbing, mocking and changing code to be testable if you can use the more useful integration and/or UI tests? They will bring in some great value without having to rearchitect code.

adwn 5y ago
Because fine-grained tests allow for more complete coverage of complex but tightly-bounded code sections. For example, if you've implemented a concurrent data structure, it's much easier to verify its correctness with unit tests; with integration tests only, it would be a lot more effort and more difficult, maybe even impossible, to thoroughly test all code paths. Of course, if your entire software only consists of trivial glue code, then don't bother with unit tests, I guess.
- marcosdumay 5y ago
  Odds are that the concurrent data structure will naturally be very testable. If it's not, it a matter of abstracting it a bit more, not of using the testability design guidebook. But well, mocks and stubs is how you test the thing, and has no relation to coding best practices. I think the GP had an unreasonable grouping here.
commandlinefan 5y ago
> Why bother with stubbing, mocking and changing code to be testable if you can use the more useful integration End-to-end tests are useful, but they take a long time to set up, maintain and run. They have to have a live database to connect to and that database itself has to conform to particular preconditions that can easily be violated even if the code itself is just fine. What I've seen, over and over, is that the end-to-end test fail because the test database instance is under load, or somebody wrote a test that inserted some data but forgot to remove it, or it doesn't work right if two particular tests run at the same time, to the point where they report false negatives so often, everybody just starts ignoring them.

tored 5y ago

Even if you have written your application in a specific manner to achieve some technical goal, for Stack Overflow that is performance, you can still have automated testing with end-to-end test or system tests. I prefer that over unit tests because a test that is larger in scale does not care how you have organized your code in contrast to a unit test. Thus you can refactor all you want and the tests stays the same. Unit tests on the other hand becomes useless when doing large refactoring because you have to throw them out or refactor them too when classes and/or functions get removed or changed.

DerArzt 5y ago
To add to this, The whole TDD approach as described in the original book by Kent Beck advocated for throwing away your smaller unit tests after a certain point while keeping the higher level ones. This way you can still be confident in your code on the local level, but you won't get bogged down in the future when you need to do foundational changes. Sometimes I get the feeling that the TDD cargo cult members haven't read the original material.

hsn915 5y ago

It's simply impossible to have reliable "best practices" in programming. It's still a young field and most of the ideas floating around are just fads. Yesterday's best practice will quickly become an anti-pattern tomorrow when another person comes along and creates a pretty looking website to promote his best practice. None of it is based on actual collective experience. Just the opinions of people who are good at marketing their ideas. Somehow if something is nicely written up and put up on a good looking website, everyone starts treating it like a well accepted best practice. Examples that come to mind: https://www.conventionalcommits.org/ https://www.conventionalcommits.org/ https://nvie.com/posts/a-successful-git-branching-model/ https://nvie.com/posts/a-successful-git-branching-model/ https://semver.org/ https://semver.org/

marginalia_nu 5y ago
> None of it is based on actual collective experience. Just the opinions of people who are good at marketing their ideas. I think often best practices are based on experience, but they stem from a lost programming zeitgeist that the new practices have replaced. Before Don't Repeat Yourself became popular, there was a serious problem with code duplication. Now there is a serious phobia of code duplication instead (to the point where it's a problem). DRY was good advice in a world where DRY was an obscure idea, is bad advice in a world where DRY is a popular idea. If you look at something like Clean Code today, it seems like a bunch of pretty bad advice, but in the context of the late 2000s Enterprise Java, it seemed like a really fresh breeze. We've already adopted the good ideas, and discovered that pushing farther in that direction was a bad idea. These books and ideas were lauded for a reason, but often that reason isn't there anymore.
- hsn915 5y ago
  > > None of it is based on actual collective experience > I think often best practices are based on experience But not collective experience. Just some people's experience. If you survey experienced people in different corners of the industry, you will not find agreement with whatever is currently being floated as a best practice. Rather amusingly, best practices are often adopted much more strongly by the beginners (and the expert[0] beginners) rather than the experienced. When you reach intermediate level of experience you start questioning many of what you learned from the internet as a best practice and start looking for alternatives or just experimenting yourself with different ways of doing things. [0]: By "expert" beginners, I mean people who got stuck in a rut. See: https://daedtech.com/how-developers-stop-learning-rise-of-the-expert-beginner/ https://daedtech.com/how-developers-stop-learning-rise-of-th... But beginners will always out number the experienced, and they form an echo chamber. This is because every year, many beginners join, but reaching an adequate level of experience to start questioning the crowd wisdom takes several years. By the time you get out of the rut of "best practices", you are in the minority. Imagine a pryamid and you're in the middle of it. There's a lot more volume below you than above you. > If you look at something like Clean Code today, it seems like a bunch of pretty bad advice, but in the context of the late 2000s Enterprise Java, it seemed like a really fresh breeze. We've already adopted the good ideas, and discovered that pushing farther in that direction was a bad idea. I kindly disagree. I think people get better with experience. Maybe a long the way you encounter many different opinions and you try out different things. But I can't say that the particularly bad advice was useful for you in your journey to improve your skills. Quite the opposite, they might have been a hinderence, and maybe you would have grown a lot faster if you were lucky enough to not have encountered them. I have no idea what Enterprise Java was like a decade ago, but I can't imagine it was much worse or better than it is now. I can't say I have ever seen a Java code base that I thought positively of. They might be terrible in different ways, but all terrible none the less.

fassssst 5y ago

“ Similarly, we don’t write unit tests for every new feature. The thing that hinders our ability to unit test is precisely the focus on static structures. Static methods and properties are global, harder to replace at runtime, and therefore, harder to “stub” or “mock.” Those capabilities are very important for proper isolated unit testing.” Is it in C#? That’s surprising. It’s relatively easy to stub and mock things out in C++, so you don’t need all these “testability” patterns, although I do find passing dependencies around as constructor parameters or properties makes code easier to understand overall.

treis 5y ago
I think they're point is that parameter passing is a performance hit they wanted to avoid. But it didn't make sense to me either. I don't know anything about C# but I assume there's some way to use compile time flags to assign static values. Seems like they should be able to mock that way.

lkrubner 5y ago

Regarding the basic idea that "best practices are not always best" I've been involved in a lot of these conversations at small startups, and mostly around technologies like Kubernetes. But every time I say something critical about Kubernetes, someone responds, "So you think Google is stupid? You think the engineers at Google don't know what they're doing?" To which I always respond: "Are you Google? Are you running 10 million boxes at 50 data centers in 30 countries? If not, you might consider a simpler approach." I do get that big companies find something like Docker/Kubernetes useful for security, scaling, and especially, dealing with the homogenous nature of the varied software stacks that typically build up in a large corporation. However, my message to the small startups I consult with is, "Keep it simple. If possible, just stick with something like Heroku for awhile, or a few big, beefy machines. You don't need High Availability, you can survive with 99.99% uptime for now. You've got an engineering team of 3 people, so keep everything simple." And yet I still get some pushback, people saying, "No, we want play in the big leagues, we want everything to be perfect right from the start." That kind of perfectionism can kill a startup. That kind of perfectionism is entirely at odds with the spirit of a "minimal viable product." Yet I keep having clients who want to prematurely imitate the best practices of Google, long before they have revenue to justify it. I wrote a satire of how some of these conversations go, which I posted here: http://www.smashcompany.com/technology/my-final-post-regarding-the-flaws-of-docker-kubernetes-and-their-eco-system http://www.smashcompany.com/technology/my-final-post-regardi...

maccard 5y ago
I work for a startup and we use k8s for our web service deployments for two reasons - there is ample material available, and there are hosted services available. As we've grown its been helpful to be able to utilise all of the ecosystem around k8s. It's been a huge kick-start for our team.

ineedasername 5y ago

I think it's fair to say that best practices are specific to goals. Low latency, overall load time, ease of scale... These will all have different (though perhaps overlapping) best practices. The trick, as with most projects, is balancing goals against methods.

csbartus 5y ago

This is a very misleading title aka clickbait. It might be true for a domain, and false in another. Yet it sounds like a general rule. For example, in my development environment, this is not true. Best practices - collected and distilled during years - are stuffed into code generators which generate skeleton code across projects and teams. They don't slow the app down, and increase app development speed with orders of magnitude.