Howdy, y’all! Greetings from sunny Austin, TX, where the tacos are hot and the swimming holes are cold. As I write this, our fair city is awash in the fun and madness of SxSW: coders and creatives from all over the world, coming together to celebrate the future (and drink some Lone Star). It’s a beautiful thing (as much as we locals tend to grumble about it … something something, the line at Torchy’s).
Ah, but, backing up: Hi! I’m Ian Varley. I’m an Architect at Salesforce, officially (and, unofficially, the Chief Beard Officer). And this is the first in a series of posts about our software architecture.
I know: you’re already on the edge of your seat! Can you even stand it?
OK, fine; “software architecture” might not seem like the most scintillating of topics. What does it even mean? Well, the right reverend Martin Fowler describes architecture as the “stuff that’s hard to change”. It’s the deep, binding decisions you make about your software. It’s the subtle choices you made early on that still impact you today. It’s the daily trade-offs you make between opposing desires: between agility and stability, features and performance, readability and optimization. In short, it’s the sensibility behind the code.
Architecture is not a subject we’ve historically written or spoken a lot about publicly at Salesforce, to be honest; at least, beyond the very broad strokes you’ll see at our user conferences, like Dreamforce. There’s a perfectly good reason for that: if you’re a Salesforce customer, you don’t actually need to know how the darn thing works. That’s the beauty of “Software As A Service” and apps running in the cloud; there’s nothing to install, nothing to upgrade. (Those of you older than the Lady Gaga era might remember that in the old days, that wasn’t a thing. You had to, you know, install stuff. On computers.)
But, of course, there is code behind the cloud: lots of it. Running a 24×7, strongly consistent, real-time, data-intensive service at scale is, as they say, “non-trivial”. We’ve got an incredible team of engineers who spend their days solving problems that most companies don’t even know they have. The solutions to those architectural puzzles are crazy interesting to me, and I think they might be to you, too.
So, this series is mainly directed at our engineering peers: to open up dialogue, to learn and to share more. What are we going to talk about? The meaty stuff: distributed systems engineering, databases, stream processing, scalability, languages, patterns, frameworks, open source (more on that over here!)… the works.
Oh, and the name? “The Architecture Files” is a nod to my favorite 1970’s detective show, The Rockford Files. Or, I should say, my favorite theme song. (The show was pretty good, but the theme song is AMAZING.)
Got a topic in Salesforce architecture you’re dying to learn more about? Let me know in the comments.
Next up: Episode 2!
