- Developer Hub
- SparkPost API
- Free Tools for Email Teams and Developers
- Slack Channel
- User Guides & Migrations
- Submit a Ticket
- SparkPost Academy
- Email Deliverability Resources
- Email Explained
- White Papers & Guides
- Webinars & Videos
- SparkPost vs. SendGrid
- Customers Stories
- Contact Us
George Schlossnagle is a pretty smart guy, though he’s too self-deprecating to really want me to say so. But there’s no question that he’s been a major force in the way SparkPost—in fact, the entire industry of high-performance email delivery—has developed over the years. He co-founded Message Systems in the late 1990s to develop a remarkably scalable email infrastructure that has grown and evolved to serve as a key element of SparkPost’s stack today. Not only is the Momentum MTA core to the SparkPost service, but it’s also essential to the in-house infrastructure at the largest mailers like social networks, ISPs, financial services, and publishers. Momentum and SparkPost together carry more than 25% of the world’s non-spam email. So, yeah, George knows something about architecting software and services that scale really well.
What does it mean to design and architect software services at scale in the cloud? I recently asked George to share some of his perspective about the role of a software architect and how it compares to other aspects of coding and building software. Here’s what he said.
How do you define your mission as a cloud software architect? What are you trying to accomplish? What motivates you in this role?
In the simplest view, I look at my job as ensuring we design and build software to not only service the requirements we have today, but that puts us into a good place to execute on the requirements that might come tomorrow. The forward-looking part of the role is probably the most difficult—ensuring that the technology and design choices we make are not only good for the problem they’re aimed at but that they interoperate with all the other portions of the architecture and are likely to remain good choices as the architecture evolves.
What motivates me is a desire to build functional software that allows us to adapt to changes in the market and changes in how our users want to use it. I’ve been building parts of this software stack for almost 20 years, and being able to gracefully evolve to handle new requirements is the key to long-term success. Many (most?) individual technology choices end up getting reevaluated every 3–5 years, and it’s setting yourself up to manage those inevitable transitions whilst still providing a stable and reliable service that’s the exciting (and necessary) challenge.
You also happen to be a co-founder of our company, so you might have a particular understanding of how technology and business goals go together. How do you see the relationship between technical goals and business goals?
I think they’re intrinsically linked. The business being successful is what allows us to continue to innovate, and innovation is what allows the business to be successful. I can’t imagine how we could be successful as a business if our technology goals didn’t directly support our business goals.
“Ahead of its time” and “vaporware” are two great monikers for failures driven by those goals being out of sync.
Does having a software architect’s mindset affect how you approach non-technical challenges, whether in the business or elsewhere?
To the extent that an architect’s job is to look at the big picture and plan for that, yes.
Have you always been a technologist in your career? Did you begin work as a programmer?
I studied to be a mathematician and began my professional career as a systems administrator. That led me into web and database performance work, and I became heavily involved in the PHP internals community, helping build an open source compiler cache for the language. From there I helped found a scalability-focused consulting company, OmniTI, which ultimately led to where I am today.
That path gave me a real appreciation for how software runs in the real world, the impact of design choices on operability and reliability and the importance of getting actionable telemetry out of your products.
What’s difference between being a programmer and a software architect? (Or, for that matter, an engineering manager and an architect?)
Being an architect is about setting a technical strategy while a programmer is fundamentally a tactical role. As an architect, you need to ensure that all of your choices and designs come together in a cohesive way that will grow over time and adapt to future challenges. A good programmer has their focus on making the individual parts as solid as possible. While there’s often some overlap, these are independent roles and both challenging in their own right.
Engineering management is distinct from both of them. Management is the art of achieving through others; of getting a group of people to all align their activities towards a common goal. It’s faddish to diminish the contribution of managers, but a good manager can really drive the productivity of teams and it is a tremendously difficult skill. People are always the hardest part of any business—navigating personalities, egos, strengths, and weaknesses.
Looking back, what’s the moment in your career you realized this was the right role for you?
Throughout my career I’ve always been interested in how things come together to form a cohesive whole. Seeing how all of the technologies fit together to solve our business issues has always been really exciting to me.
What are you working on right now?
We are moving to the next generation of our cloud architecture now, and that’s an effort that’s spanned most of the development group here. I’ve also been active in driving a lot of our compliance technology (trying to keep malicious and unwanted users from exploiting our platform).
What’s your most important tool?
My most important asset is a phenomenal team of great people who have a great understanding of all the technologies we have. Being able to leverage that group to make informed decisions is awesome.
You’ve designed on-premises and cloud technology products. What’s been the most startling difference between architecting for the cloud instead of a more traditional, packaged software product?
I don’t know that there’s anything particularly startling. The biggest non-startling difference between architecting for the cloud is that it flips many of the traditional challenges of release software on its head. In an on-premises world, you have to be extremely conservative about quality control, because when you release a version into the wild it becomes its own entity and you cannot force your customers to upgrade. When you control the entire deployment cycle yourself, you can iterate much faster because you can instantly (and globally) roll back from any issues. This allows for a feature velocity that is tremendously larger than on-premises software.
What’s a misunderstanding about software architecture you wish you could dispel?
I think the (false) notion of hierarchy is a common misunderstanding. Recognizing that the best architect may not be the best programmer (I’m certainly not), or that great programmers may not be great architects. They’re different skill sets and reinforce rather than eclipse each other.
What should I have asked you that I didn’t?
You were pretty thorough. 🙂
I hope you enjoyed this window into how one of the principal architects of SparkPost sees his profession. The thoughtfulness with which George describes his point of view as a software architect and builder doesn’t surprise me at all—in my experience, it’s a hallmark of how George approaches most aspects of work and communication.
The community of developers working with SparkPost really has stepped up in the last few months: submitting pull requests, writing new client libraries, finding bugs, and helping each other out in our community Slack. They say you are the company you keep—well, if even a small bit of your collective awesomeness rubs off on us, we’ll know we’ve made it. 🙂
We’d like to show a little bit of love in return by highlighting some of the community members who’ve helped raise the bar for SparkPost and our tools. Today, I’ll start with Darren Cauthon, who contributed the SparkPost C# client library. I asked Darren to share a little bit of his point of view.
How long have you been a developer and what got you started in the tech world?
I’ve been a developer for over 15 years. I got started with tech in my sophomore year, right around the time my college forces students to pick a major. I thought about being a music teacher or going for a general “business” degree, but I remembered that programming in QA Basic in junior high was fun. So I signed up for my first C++ class and never looked back.
What do you like most about being a developer?
Working with all types of people to solve new problems. The tech is fun, but using it to solve actual problems that exist in reality makes it very fulfilling.
What led you to contribute to open source projects?
Two things. First, I got over the fear that my code wasn’t good enough. Second, I’ve found it’s hard to grow as a developer when I’m limited to solving the problems that my business has. Open source provides the opportunity to solve problems that I’d otherwise never think to solve, and it provides a chance to work with developers I’d otherwise never know.
How did you find SparkPost?
My company was about to deploy a new Mandrill solution when their big shakeup occurred. We looked for alternatives, and my boss noticed SparkPost due to your relationship with Port25 (which we used for other solutions).
What prompted you to create the C# client library for us?
I saw there wasn’t one, and I wanted the experience of writing the library. I’ve learned a lot about email processing and C# features while working on the library, and that’s knowledge I’d never have gained otherwise. I’ll be able to apply that knowledge to many more things than just this library.
What’s the hardest thing about contributing to an open source project?
Saying “no” to contributors. Sometimes someone may offer a pull request with a feature or change that doesn’t fit. I hate having to say “no” and reject what another developer has spent time writing. But luckily I haven’t had that problem with this library, as we’ve had a great group of developers contribute new features—and every contribution has fit.
What are you passionate about outside of work?
I have a great family, and raising kids is fun. I’ve been a tuba player for over twenty years, and I’m slowly working towards a black-belt in Tae Kwon Do. I have a 2016 resolution to beat Ninja Gaiden without dying, so I like older console gaming. But my first passion is still programming.
I was really glad to have a chance to talk with Darren and learn more about his point of view. His project really has been a great addition to the ways folks can use SparkPost. Thanks, Darren!
Do you have an idea or project to contribute to this great community of developers? Give us a shout on the SparkPost community Slack, and you might wind up in our new community features series.
p.s. you can check out another one of Darren’s C# libraries here.SparkPost © 2018 All Rights Reserved