published on 4 September 2015

As the countdown to PuppetConf continues (it’s just a few weeks away!), we’re looking ahead to the talks, training sessions, and demos that’ll make this year’s conference memorable. Today, we’re talking with Paul Ambrosini and Jeff Malnick from SRC:CLR, about their session on vertically scaled design patterns.

When: Wednesday, Oct. 8, 2:30 p.m.

Going to PuppetConf? Add the session to your schedule.

1. Tell us a bit about your PuppetConf talk, “Vertically Scaled Design Patterns” and what participants can expect to learn and think about.

Paul Ambrosini: SRC:CLR started just like most initial apps, a large bulky pile of code. As we encountered various challenges each one seemed like a little problem here and there. As we grew the system became much more complex, each little problem added up and it became an ops nightmare. No one wants to release a whole new build to change a spelling mistake.

What SRC:CLR has done is iterate over and over on these problems, solving each one as they’ve shown up. These iterations have shown us that there are patterns that will wind up hurting you as well as patterns that are workable at different sizes and stages of a company.

I was once told there are no “best practices” in DevOps. While somewhat true, there’s at least simple patterns to follow and we’ll talk about some of them.

Jeff Malnick: Every ops person has a depth of experience in provisioning custom services. Those services tend to have specific port definitions, and other layer 7 configuration that was traditionally codified statically with configuration management. This system has worked for a long time, but in the age of micro services it becomes more difficult to deploy ephemeral services with statically defined configuration (such as port assignments for the service).

Configuration management is great for defining static state, but when it comes to dynamically provisioning ephemeral services you need something that can track service state and set it dynamically. In our talk, we'll see how we went from statically provisioning our backend services with configuration management, and what we learned in the process. In the end, you'll gain a greater understanding of why it's important to leverage a dynamic service schedualer (we use Apache Mesos via Mesosphere's Marathon utility) along with configuration management to deploy services, in particular docker containers.

2. What kinds of projects and challenges do you tackle at work, and what do you find most rewarding?

Paul: I’ve been at SRC:CLR from the beginning and have tackled almost every challenge together with our team. As we’ve grown I led the team from a single deployment into a micro-service architecture and orchestrated our API design process to allow the least amount of blocking time for all developers.

Jeff and I worked closely together to build our CI process which at this point is just merging to a branch and going to get a beer. It’s got a little more to go but it’ fantastic!

Jeff: At SRC:CLR we're solving some of the most important problems around security, at the core of the software engineering: the source code. Every day, we come to work and challenge ourselves with building systems that can aggregate huge amounts of data and metrics and bring that information to our end users in a friendly way. Whether it's our terminal application or our platform, our toolchain leverages a massive amount of systems engineering to make sure source code stays clean.

The most rewarding work for me is that which intersects both big data and systems engineering. For example, building a system that can securely build our customers code base in a multi-tennant environment. Sometimes, just getting a trick CI pipeline in place so our developers can "merge-to-environment" in git and automatically deploy to a specific environment is very rewarding as well.

But above all else, I love writing new tools to help our developers gain faster, more reliable insights to the application at large. That includes building a tool to get the running versions of all our services across all environments or something to effectively "tail" logs that are aggregated to elasticsearch, but on the CLI instead of in Kibana, for a more native log query experience.

3. What is one thing everyone should know about IT automation?

Paul: Automation is great but make sure you’ve got your networking stack down before going too far with anything else. If your boxes can’t talk to each other your automation doesn’t matter.

Jeff: Don't get into this business if you want to live a well-adjusted life.

4. When did you first learn about Puppet?

Paul: When Jeff switched our ops code to Puppet.

Jeff: The year I worked at Puppet Labs as a Professional Services Engineer in 2013.

5. PuppetConf is in Portland this year. Anything you're planning on doing during your stay, outside of the conference?

Paul: Finding a good whiskey bar.

Jeff: Seeing friends, and drinking heavily.

Paul Ambrosini is the co-founder of SRC:CLR. Originally a security consultant, Paul started his career pen-testing some of the world’s largest companies. After a few years he co-founded SRC:CLR with the hopes of building software to let develops write more secure code. In his free time, he can be found on his Triumph on any given curve in the Marin headlands, drinking rye or bantering about the finer points of secure systems engineering with his colleagues.

Jeff Malnick, is a DevOps Engineer at SRC:CLR. A graduate from Puppet Labs' professional services, Jeff has been a systems engineer for 10 years, starting with the Department of Defense at the Naval Postgraduate School to currently working for SRC:CLR, the foremost platform that brings software security to the development process. Outside of the day-to-day, Jeff loves tearing up single track on his mountain bike, building pillow forts in his living room and finding new and often overlooked uses for glitter.

Learn More

Share via:
Posted in:

Add new comment

The content of this field is kept private and will not be shown publicly.

Restricted HTML

  • Allowed HTML tags: <a href hreflang> <em> <strong> <cite> <blockquote cite> <code> <ul type> <ol start type> <li> <dl> <dt> <dd> <h2 id> <h3 id> <h4 id> <h5 id> <h6 id>
  • Lines and paragraphs break automatically.
  • Web page addresses and email addresses turn into links automatically.