ProdESP32 #6: How to Choose Tech

I get this question a LOT and many of you in the community have expressed interest in knowing more about how to answer it.

Which X should I use?

Which cloud provider? Which chip? Which programming language? Which MQTT broker? Which database? I’ve seen a ton of content on the internet explaining why technology X won’t scale, or why chip Y should never be used in production. This is the voice of inexperience.

The shocking answer to these questions is almost always the same….It Doesn’t Matter! But not in the way you might think.

I probably just lost over half of you but bear with me. This post could span an entire book but in the interest of keeping it short enough to illustrate a point we’re going to focus on making choices in the following areas:

• Cloud Provider
• Main SOC (system-on-chip) Microcontroller
• Programming Language

We’ll wrap up with a general overview of how to approach the “Which?” questions you’ll encounter in your projects.

Which Cloud Provider Should I Use?

Some people will tell you that AWS is the only conceivable option and has “won” the cloud provider battle. Others will swear Azure is broken and awful or that GCP is better than them all. Guess what? Massive companies bigger than any scale you will have to worry about for years, if ever, are built on all three. So which one should you choose? The one you are most comfortable with. The end.

So when does it matter? Well, if your nephew comes to you and explains he’s launching the AWS-killer Dan’s Cloud Compute you are going to want to steer clear. What you care about are important metrics like maturity of the platform and it’s product offerings. Every cloud provider will have outages and edge case bugs that you will have to work through. It’s foolish when people encounter an issue in AWS and think “If only we had chosen Azure”. Azure and Google are going to have their own unique problems. That’s a given.

Right now the 3 front runners are AWS, Azure, and GCP, so pick one and move on.

Which Main Chip Should I Use?

Coming to a site named “Production ESP32” you might expect the answer to be “Well, duh, the ESP32”. But it would be terrible advice to blindly tell you the ESP32 is the one chip to rule them all. There are dozens of manufacturers producing hundreds of product lines across thousands of chip SKUs. If anyone tries to tell you that a specific one is the only “right” one then at least you know they are a terrible source of advice.

Compute power, peripheral support, IO capability, memory, clock speed and many other factors all need to be considered when selecting a SOC microcontroller. And all that before even mentioning price. How much will you be able to sell your product for? What kind of margins do you hope to achieve? Does the math work?

What about availability? You’ve spent 2 days selecting the perfect chip that has exactly what you need at exactly the right price point. You order samples and make some PCBAs. Everything is great until you realize they are virtually impossible to acquire in volume (this happened to me on a previous project). Back to the drawing board, weeks wasted.

When it comes to choosing the brains of your project the decision is a bit more complex than the cloud provider question. But here are some things to consider:

• Feature set (IO, memory, CPU, etc)
• Availability in the volumes you anticipate
• Familiarity. If you have spent 5 years using STM32 chips, switching to ESP32 is going to create more problems than it solves.
• Price
• Power consumption
• Documentation
• Community

Again, start with what you are familiar with. Unless it has a glaring deficiency, i.e. you need 50 IO pins and it only has 30, move forward.

Which Programming Language is Best?

Let the religious wars begin! Spend 10 minutes reading LinkedIn or Reddit and it’s obvious Rust is the solution to all embedded problems and C is dead. Go to some other forums and many will tell you C++ was never intended for embedded applications and C is still the only “serious” choice. I recently saw a comment on LinkedIn that said “But honestly, if you are building actual embedded products assembly is the only option.”

C and C++ have been around for longer than most self-proclaimed language critics have been alive. Rust, while still a kid in terms of language age (first stable release less than 10 years ago), is already getting consideration as a second language for Linux kernel components. And listen, if you can write assembly as fast or faster than you can write C or C++ then, first of all, I bow to your nerdy prowess, and second, go for it.

The point is, the programming language is not going to be the thing that makes or breaks your firmware.

What about for your backend? “Stay away from PHP, gross!” And yet, there are sites much bigger…and more profitable…than yours humming on PHP. Javascript or Typescript? What about Ruby on Rails? Go seems to be all the rage. The language question seems even harder when considering the backend because there are so many more options. Which one is the best?

You’re asking the wrong question. What you should be asking is which one can I leverage to get my product shipped as soon as possible with high quality to my customers?

Again, it’s all about what you are familiar with or what your team is familiar with. Do you have 3 friends that are experts in Ruby on Rails and looking for a project to work on? You just made your backend language decision. As with the cloud providers, every major language is capable of satisfying the Pillars of Production. Pick one based on your circumstances and go for it.

Here are some things to consider:

• Maturity of the language.
• Community. How easy is it going to be to find answers on Stack Overflow?
• Familiarity. Learning a language while trying to create a product is a recipe for failure.

Notice I didn’t mention scalability, speed, or security. Those are problems created by developers. An expert PHP developer will create a faster, more secure, and more scalable backend than an inexperienced hotshot that thinks only Ruby on Rails is the solution.

The shortcomings most people cite as reasons for not choosing a programming language are often experience gaps, not language gaps.

Which _______?

Mongo or Postgres? Mosquitto or Paho for MQTT? FatFS or LittleFS? You will encounter dozens, maybe hundreds of technical decisions and if you aren’t careful it can paralyze you. You’ll waste days, weeks, even months researching and reading opinion pieces because you’re terrified of making the wrong decision.

Don’t let this happen because the good news is it usually doesn’t matter. Not because the technical decisions we make are unimportant. Quite the contrary. Those decisions are extremely important but almost all of them aren’t make or break and are often very forgiving. You may look back and wish you made a different decision. That’s normal. But it’s also extremely unlikely that the reason your product failed is because you chose C++ over C or Postgres as your DB over Mongo.

I want you to remember two things. First, your customers don’t care at all what tech exists behind your product. You are leveraging technical tools to solve customer problems. As developers we sometimes get mired down in the beauty or elegance of the technical, but what matters most in a production setting is your ability to deliver customer solutions, regardless of the tech used.

Second, success can help fix almost any suboptimal technical decision. You just sold ten thousand units and realize you made a mistake in chip selection? Congratulations! You just sold TEN THOUSAND units! You’ve proven product-market fit. You hopefully have some profit sitting around. Use that profit to address a redesign for v2 which will be even better and customers will love even more.

So how do I make my technology decisions? Simple. I start with what I know best and have the most experience in and then make stuff. If I encounter shortcomings in my tech stack I try to quickly evaluate if it’s an experience gap or a real showstopper that requires a complete change of direction. Most times I find it’s the former, not the latter.

Conclusion

Choosing technology for your product ties into all of the Pillars of Production. The technology choices you make will impact how deterministic, secure, maintainable, tested, and scalable your product becomes. But not in the way most novices would have you think. Most mature offerings today can achieve all of the pillars but much of that depends on your ability to do so with them.

Use your strengths and experience to your advantage and ignore the sideline pundits who love to speculate on the viability of technical offerings more than building actual products with them. And avoid, at all costs, people who tell you they know the one true solution for any part of your stack.

Join the community and get the weekly Production ESP32 newsletter. Concise, actionable content right in your inbox.