Arpit MohanI share TL;DR versions of articles on software engineering that I read every weekday through my newsletter - in.snippets(). Sign up hereto receive these in your inbox.
10 Lessons from 10 Years of Amazon Web Services
Werner Vogels, CTO of Amazon, wrote this post three years ago when AWS completed 10 years. At a time when I am constantly thinking about & making engineering choices at my startup, these are some great fundamentals to follow.
1. Build evolvable systems: Keep the possibilities & scale of the future in mind. Build an architecture in which you can introduce new software components without taking the service down.
2. Expect the unexpected: Everything eventually fails over time. Many failure scenarios will be unknown at design and build time. Build systems that embrace failure as a natural occurrence.
3. Primitives not frameworks
4. Automation is key
5. APIs are forever: Designing APIs is a very important task as you’d only have one chance to get it right.
6. Know your resource usage
7. Build security in from the ground up: To build secure services, it is necessary to integrate security at the very beginning of service design
8. Encryption is a first-class citizen: Encryption must be a high priority for your business because it is a high priority for your customer’s business.
9. The importance of the network
10. No gatekeepers
A quote I liked in this article:
“There is no compression algorithm for experience.”
Read the full post here.
9 mins read
Java debugging at scale: when rare events become commonplace
Through this story of debugging an intermittent problem with Jira Cloud expounds on the nature of problem solving in a large and complex software system.
Salient points from this post:
Problem solving can be a very iterative process, asking questions whose answers which lead to new questions is part and parcel of the process.
Debugging some things will take iterations of logging in production. With large and complex systems, one can’t always reason about the system’s behavior. Sometimes you will need to add code to determine what is happening in production.
Debug the happy path to find the initial symptoms but remember that doing this is just the first step on a long journey.
Dead ends are also information. They make you backtrack and re-examine what you know.
Read the entire story to understand the step-by-step process of digging deeper into the problem that led to effective debugging.
9 mins read
The Most Common Pitfalls for an Inexperienced Developer
These are some common mistakes all developers make. Though written for beginners, I think this post has some good reminders for all developers. Being aware of these mistakes and knowing how to avoid them can help every developer in their career.
Reimplementing Code That’s Already Available in the API: The devil is in the details. Always look at the documentation before you start writing any code.
Making Things Unnecessarily Complex: Don’t do fancy stuff like quirky one-liners and overly complex abstractions. Make code simple, not complex.
Silently Swallowing Errors: Track down the source of the problem, don’t just “fix” the bug.
Overconfidence: If you don’t know what you don’t know, you don’t know how much you’re missing.
Switching Tools: Do the research, pick your tools, stick to them & master them.
Only Testing the Happy Path Scenario: Write tests for edge cases.
Focussed on the Tech and Not the Business: Always know how your work impacts the business.
Check out the full post here
5 mins read
About When Not to Do Microservices
All businesses have to deliver value to customers. But when you are just starting out, you don’t know what will deliver value. Everything you think will deliver value is just an assumption. The answer to “when not to do microservices” lies in knowing which part of the “value delivery” lifecycle of your business are you working on. An analogy describing technology teams as Pioneers, Settlers & Town Planners help us in understanding this.
Pioneers experiment with wild, divergent approaches running many experiments hoping to reduce uncertainty about what may bring value to a company in 3+ yrs. This “pioneering” effort leads to a few options that can be built upon and taken to the next level. The “settlers” end up building these options. They figure out how to scale product engineering and also work on building the ancillary pieces in the organization to make the product successful in delivering differentiated value. Over the years, these once new products will no longer be uniquely differentiated but will still deliver massive value. Town Planners are the people who work on such products.
If you are the Pioneers, sticking with the monolith is almost always the right choice. You have to run a lot of small experiments, build many MVPs and throw many of them away. A monolith is always the faster option in this case. When you are the Settlers, think of using microservices once you have figured out which of the experiments likely to deliver value are actually delivering some value. When you are Town Planners, microservices help you optimize for speed and can be a good option.
If you are thinking about your architecture choices, you must read this post by Christian Posta.
5 mins read
P.S - This is a list of the best of tech articles that my team at Appsmith reads through the week. I share it here every Saturday. Would love to hear your feedback on this.
If you want to know something about me or from me, I started an AMA here.
