I don't think it's a scoping issue (member variables don't compose a scope - it's just an implicit reference to an argument) but yeah I don't like how the decision to generate an implicit reference depends on where in the block you are.

Good reading on microservices:
And more good reading from the comments. https://www.stavros.io/posts/microservices-cargo-cult/ and http://martinfowler.com/bliki/Micros...equisites.html

Here’s some comments that hit home with me:



I'm starting to think the startup I've been working at should have just taken the monolithic, then break it up later approach, especially since they don't seem to take DevOps seriously and are like - well we'll just figure that out as we go after the alpha.

Whereas at the giant company I work for microservices solve a whole lot of institutional problems. However that's assuming we can ever come up with a sane infrastructure approach that doesn't involve 6 months to build out 1 microservice environment pipeline. I'm not optimistic about that.

ChrisV, I'm sure you will hate this... well, I don't think anyone will like this much at all:

I was having a bit too much "fun" seeing what Ruby is capable of, but early impressions is that Ruby is what Python should have been.

I've never seen that syntax fit declaring private methods.Typically you'd just declare your public method at the top and then have a private section like so

everything below "private" will be a private method.

is anyone here really good at python?

define "really good"

I'm pretty good, I'm sure lots of other people here are also.

I personally think monolithic (or at least just a couple of really completely obvious separate monoliths) is better to start out. And even then you can be surprised how something you thought was obviously necessary actually isn't.

Punting on devops *might* be ok. I think it depends a lot on your industry, product, and what the relationship with customers might be.

It feels like the answer in cases like this is to give more autonomy to individual groups in the company. The high level direction becomes "You need to provide and support this service for the rest of the company". Let them figure out how to build it / operate it / maintain it. Then encourage/support a lot of cross-team dissemination of knowledge/tools.

Yeah microservices (well like anything else in software) for standard web apps and such are more about solving social and institutional problems that come from having a shared responsibility over something that is too big for anyone to understand. In a monolith, it becomes hard to say who owns what code, who owns what data and data models, who is responsible when X breaks and who should have veto power over certain types of decisions. Hard boundaries can make management easier and keep people accountable - it's much easier to say, your service was down than to say, your code leaked memory so this other code that I wrote stopped working. But the overhead is real and in general you shouldn't go there until you're forced to. It's much easier to break up a monolith than to consolidate microservices.

There are exceptions (maybe one service has to scale out to 1000 machines, another is fine on 5) but again, it's rare to run into situations like this without also having a correspondingly large engineering team.

This is easier if you have a strong shared group norm and have pragmatic leaders throughout the organization but otherwise, you just run into a situation where every team has their own pet technology framework and stacks are just gratuitously different in a way that puts a lot of pressure on operations and cross-team communication. Also a lot of internal services can't easily be provided without enforcing some kind of uniformity and the meaning of "this service" is a moving target.

My experience with services is a sample of one but in most cases I saw stuff like:

* service is built very fast to meet some vague need, sucks in some fundamental way, and is then abandonend and either used for one thing or never used

* someone tries to port a piece of the monolith that is important but hairy, gives up, now we have a half implemented service and still have the monolith

* people walk around saying the monolith will be gone in 6 months even though the monolith itself contains at least the last 3 solutions to particular problems with no sign that those 10 year old solutions will ever disappear

* The people responsible for settling on and implementing infrastructure shrug their shoulders and say "do whatever you want, we literally do not care"

But, you know, that was a dysfunctional workplace which is why I wanted to leave. So I wouldn't say it's necessarily representative. My group was the first one to get a working service deployed and it was really an improvement to my daily life not having to work in the monolith. There are definite benefits.

But a tech solution can't solve a social problem

Everything is easier with a "strong shared group norm and pragmatic leaders".

I'd argue that operations shouldn't be a monolithic thing for the whole organization - just like the services. So you don't need to worry about one group providing support to many different tech stacks.

And I think the definition of the service should be independent from the technology stacks behind it. So an internal (or external) service can easily be provided to other teams w/o those teams needing to know how its implemented.

That's not to say things are perfect and this is a magic bullet. But I think in general its better than the alternative.

Touche.

The problem is that at some level, you need a view of the whole system and it's not efficient for individual teams to own all aspects of the operations. At a certain scale, there's a need for some kind of platform team that both provide the tools that make operations simpler and consistent across teams and also enforce standards that teams must follow for there to be appropriate reporting and escalation of issues. Also, simply leaving everything to individual teams also leads to siloization because one team has no view into how another team functions. At a lot of companies, this means no common source control and no common service interface. A lot of features cut across service boundaries.

What you're saying makes more sense at a larger size, say, 200-300 engineers but not 5-7. It's very difficult for a team of 5-7 engineers to own all aspects of operations for a complex internal service consumed by multiple other engineering teams, who in turn serve millions of customers.

The problem is that you can't control the definition of the service tightly at the top either - teams have to own the interface definition as well since it's a constantly evolving thing. With no standards, you end up with 10 different RPC protocols, no consistent tooling or documentation around how to access these differences and some teams resorting to screen scraping tools because they don't even know how to work together.

This is fine when other teams are dependent on your service on a purely feature basis but again, there's a scale at which other teams have to know how your stuff works. There are many teams, like devops, security, incident reporting, product, customer support, test engineering, etc, who aren't necessarily consumers of your service but need to work with you on the details.

Candybar I feel like all your posts are for post-grad level infrastructure teams, when every I've worked it's more like toddlers playing with blocks. Although we did have a really good DevOps guy who patiently helped direct the toddlers. Took several years and they still only run a few of his automated scripts.

The big parent company now is back to toddlers with no DevOps guy to help. And the startup doesn't even know what DevOps is. They're just winging it. Sigh.

To be clear, I'm not talking about teams of 5-7 people. I'm talking about at a big company with 4-digit+ engineers and groups of people with dozens to hundreds of engineers.

And while I recognize there are some teams that should have a bigger picture view, they should generally be reactive, promoting things that work, refining things that work, building tools that have proven useful or needed, etc. rather than figuring out what they think should work and trying to force that on everyone else to use. The example again, is something like one team figuring out a micro service architecture that all other teams then have to use.

Yes, there are some exceptions. Security is a big one because the requirements of security are very fixed. But a bunch of the ones you listed I don't think should necessarily be exceptions. For example, the whole idea of having one overarching devops team for a big company, kind of defeats the purpose of devops, imo.

I think we're largely in agreement but someone who's in charge of hundreds of engineers is almost always going to have enough power to make that call. I don't think there are many companies in the world where you're not autonomous at that level. Dysfunction usually goes the other way (lack of common standards, information silos, communication failures, us against them mentality, etc, lack of shared cultural norms across the whole organization).

Agree with this but I think you're describing a problem that rarely exists - platform teams at big software companies simply don't have the power to impose much except in very specific cases that are driven by executive decisions. It's just helpful if certain standards become understood by the leaders throughout the organization such that they are followed regardless of whether they are directly enforceable from the top. And platform teams can incentivize this behavior by creating and providing useful services that require using shared services/tools.

A devops team at this scale would is something more like a value-added version of AWS, CI and related services - individual teams are responsible for day-to-day operations and plugging into this infrastructure. This is important because at this scale, out of the box tools don't really work very well and/or require significant customization or at least common boilerplate to allow the organization to work together. Also, even an absurdly large service like Facebook is, for the most part, a single entity to the users - this requires a lot of central coordination. Obviously if your teams are producing separate, unrelated products that don't need to be coordinated, that changes things.

So far from work I've learned:

• Passive aggressiveness
• File organization is for idiots
• Testing is bad because it takes time
• Have different code conventions based on language and file type
• Do not plan ahead
• Speed > accuracy
• <20% of your time working should be doing "work", the rest should be faffing around doing paperwork and wasting time wading through a sea of poorly structured code (ex. 500-line function, well over 80-chars per line)
• Have no style guides
• Let any random person make graphic design decisions

All good habits and such, right?

Standard.

Is this your first job?

Dev job, yes

Highlighted all the ones that apply at my work place. No one in my team can touch type so forget speed>accuracy. I once had someone get angry with me when i told him that some of the stuff he had done was super fubar. Like, he must have purposefully ignored edge cases or didn't even bother to make sure his code worked. Completely broke the page (page would hang for minimum of 45 seconds when clicking on a certain dropdown).

Seeing dysfunction first-hand is definitely going to help you appreciate your situation when you're at a better place. As long as you're not in it for too long and don't become emotionally damaged, seeing examples of what not to do is also good for long-term growth.

With that said, the list you came up with is quite underwhelming. You could say most of those things about lots of organizations/teams that are actually run decently and pay their people very well. If you've never worked professionally before, it can definitely be a shock how chaotic the process of real-world software engineering is, even at the best-run places. It can actually be worse at the best-run places because success and growth tend to exacerbate these problems and top engineers can remain productive (thus contribute to even more success and growth) even in objectively terrible situations.

lotta hyperbole itt

@noodle :

Since you mentioned 500 line functions... the worst I've seen in my code base was a 750 line switch statement or maybe it was a 50 line function that was copy/pasted into 18 different files. You tell me. The first was so atrocious I just let it be. The second, I declared it in one file then used a partially applied function call everywhere it was needed. There was one jquery selector that changed in a few files so I just used that as the parameter in a partially applied/curried version of the function that was declared once.

Really? After essentially one week, it's normal to notice much worse as a complete novice?

From whom iyo?