Interested on knowing how's developer experience across other big techs, from language/ coding/pushing code/ building /deploying. I have worked in 2 different teams in AWS which deal with separate set of build tools and completely different developer experience. You can say that I've worked on foundational services (stuff that cannot take dependency on AWS services) and also services that run on top of AWS. For example, whenever I worked on foundational services, I mostly dealt with - Writting java code in intellij (using coral rpc framework) - ruby + LPT to define infrastructure - brazil to build code into assets - internal git servers to push code - amazon pipelines to deploy to individual stage (gamma/zeta/prod) - Apollo w/ hardware on legacy fabric - bunch of perl scripts to glue the deployment process using the apollo framework in the host - metrics pushed to PMET (internal metric framework somewhat that resembles prometheus but precedes it) and alarms are handled by carnaval - load balancers are internal VIPs (some of them software some legacy are hardware) - logs are pushed to internal logstorage system - Internal distributed database (resembles somewhat dynamo) Whenever I started dealing with services that ran ontop of AWS fabric, we used: - Java for long running services (still coral), using intellij - Python for lambdas, typescript+cdk for infra, using vscode - brazil to build everything - code still pushed to internal git - amazon pipelines - assets are built to s3 instead of apollo packages - CodeDeploy to deploy assets into "cattle" hosts on AWS spun up by cdk - asset bootstrap is done by apollo frameworks perl/bash scripts - we use public offering (ELB/ALB) for load balancers - all metrics/alarms/logs are handled by cloudwatch - Also used public offering for databases (dynamodb, elasticache) Working on foundational services, we barely used any of the public offering services of aws, with a few exceptions like S3, SQS, SNS. I can say that I only logged into AWS console like 1 time per year. I used to think that all this knowledge I had on the internal systems was useless and I would never ever use this somewhere else in the market. However when I transitioned to a team that built services ontop of AWS, it was night and day. I was able to learn more and more about AWS and how to work being a "customer" (having to deal with throttling, AWS accounts, AWS service bugs, scaling, etc) and to be honest, some times I miss the internal tooling even though using AWS provides better documentation. Weirdly I created a passion for builder tools and figure out how companies handle the process given their scale. Having said that, I was able to read some of google/meta research papers on tooling they use to build/deploy/maintain their software running, but there are a lot of gaps or how do they connect to each other. So how's the process in your company ? What stuff do you use ? #meta #google #buildertools #developerexperience
Mercurial monorepo, blaze for build tool, Borg for everything production, internal cider will eventually be the only supported IDE Can’t give much more details, but infra tooling is pretty consistent across the company. Languages and frameworks are more fragmented but not too bad.
I've read some papers on piper for monorepo. Did google ditch it? Also does google have some sort of pipeline to deploy to stages?
1: Nope, still holding strong. 2: Yes, proprietary stuff, very mature though, have canary baking, percentage rollout, fast rollback, etc. I have yet to see any SaaS solution comparable.
Tech Industry
Yesterday
861
Programmers are the smartest people in the world
Tech Industry
Yesterday
208
Do you drink coffee
Personal Finance
7h
1510
Retire by 45? Rate my NW, lifestyle creep and portfolio
World Conflicts
Yesterday
793
Blind is an antisemitic cesspool
India
Yesterday
1052
Why Worshipping Lord Ram Important in Hinduism?
Good tools used to be exclusively large companies. Many of these tools have been made open source/public and there are thousands of SaaS startups in the tools space. Companies with good tool stacks now are basically young companies that have adopted this new paradigm and older companies that have invested in the space.