De-Coder’s Ring

Consumable Security and Technology

Month: November 2017

Startup Series: Life at a Startup

My colleagues know (since I talk A LOT) that I’ve had a long loving history for startups.  Like, Honest to God, hired by the founders as the first engineer (twice) kind of startups.

The first one was a very slow process to go full time at nPulse Technologies.  Randy, the founder, and I had been friends for years.  He started this packet capture company as a lifestyle company.  Something fun to do, enough to make a living, but that’s all.  For a while, I’d bill him $500/month to write a web app and some APIs to pull packets off this appliance.  We didn’t do the SaaS thing, or the PaaS thing.  We built a linux based server that had our software running.  After a few years of that, he and his co-founder decided they wanted to make nPulse a real thing.  He pulled me in as VP of Development, and it was off to the races.  By the end of the first year, we had approximately 5 full time employees.  2 more years, and we were up to 30 by the time we got acquired by FireEye.    I stuck around FireEye for a bit, but decided it wasn’t for me, and went to a big bank.  It had been approximately 10 years since I worked for a Fortune 500 company.

After two years of ups and downs (yeah, I keep it real in my blogs), I got a call out of the blue to join another company as VP Engineering.  This one was different.  I started day one with another developer at Perch Security.  The founder hadn’t quit his day job yet, but he had landed enough funding for us to get started.  I got to build a network monitoring appliance, that shipped MASSIVE amounts of data to a cloud service running at AWS.  There, data went through a pretty big orchestration to ultimately land up in Elasticsearch for storage and search by customers.   Speaking of customers, we started signing them up early, and often.  I stayed there for 14 months, until I was confident the infrastructure and code was solid, and due to many reasons, came back to the previously mentioned big bank.

Here are a few observations:

Startups are HARD

There’s no such thing as a slow day, if you have customers.  Customers demand quality (duh) and if anything goes wrong, you have to fix it immediately.  There’s no “oh, I’ll fix it when I come in in the morning”.  Small bugs, big bugs and crashed systems.  It was critical we kept everything top notch, especially when we were trying hard to find new customers, and leverage the good will and good word of our early ones.

Scaling is HARD

Five network sensors is easy.  It looks like things will scale, since all the tools are there to scale…. then one day, it stops scaling.  Add nodes, it still doesn’t scale.   Something is wrong.  Rewrite… and fast.  I switched data platforms three times with no downtime or loss of data.  Using intermediary queues like SQS, Kafka, etc is critical for scaling.

Building things is fun!

I shine when I get to build new things.  Give me a whiteboard, and I can fill it up with a pretty darned good solution.  Building an MVP is my dream job.  I get to write just enough code to prove a point, or try out a new approach.   Then it gets harder

You can make a big impact

You can make a big impact at a large company.  You don’t need a tiny company to make a big impact.  Heck, I think I make a bigger impact here.   At my last startup, Perch Security, I had a team of Cyber Security Analysts and a team of engineers.  We were up to around 30-35 customers.   That was awesome!   I could say “I built this!”..    at the bank, I’m supporting our messaging platform as the embedded technical lead, technical platform owner, whatever you want to call me.  A huge enterprise platform with over 150 developers that sends notifications and emails to every customer account holder…   Talk about an impact!

Good and Bad

Startups can be a blast.  They’re not all foosball and free lunches.  It’s collaboration at its finest, because you know everyone involved is onboard 100%, or they will lose their job.  Not by being redeployed in a down economy, but, because if they fail to deliver, the company goes under.

When a startup succeeds, and grows, and gets acquired, then it can be REALLY rewarding for those early folks (I’m still holding out hope on my Perch stock!)

Want to talk about startups? hit me up!.

Podcast – Jon Bodner

This week, we branch out a little from the previous topics of Cyber Security, which we’ll be back to soon, don’t worry.   (that was a lot of commas in that sentence)

Today is an interview with Jon Bodner.  Jon is a very popular writer and speaker on all things software development, with a new focus on the Go programming language.  I’ll add a few notes here to find Jon’s various talks, but, please subscribe and listen to this episode!

You got your engineering in my data process

GopherCon2017 – Runtime Generated, Typesafe, and Declarative: Pick Any Three

The Story Behind Capital One’s Fork Of An Open Source Project

Flexing those Writing Muscles

An interesting thing happened to me this week.  I got asked to begin blogging publicly for my employer.  What??

About a year ago, I decided to start blogging regularly.  I’d blog here at fauie.com, I’d blog on LinkedIn and try to maintain myself on Twitter.

About 10 months ago, I got asked to build a video course on Neo4J, a NoSQL/graph database.

Before that decision a year ago, I was petrified of speaking or writing publicly.

“But Chris, you’re super smart, and funny and all the folks like you!” – said no one

Even if they did say that, it doesn’t matter.  The level of self-doubt that I held was paralyzing.   I knew I could code, I knew I could design big integrated solutions of software, but man, writing? Not my thing.

I was always afraid of not being the ‘best’.  I was always comparing myself to the smart people I know.  I was worried that people might not read what I put out there…   Imposter syndrome is an amazingly hindering affliction.   It’s real.

I’m not sure if it was just the right time, or my maturity or just realization that it didn’t matter if I was the best, but I started writing, and I’m really enjoying it!   Some people read my blog, some people listen to my podcasts, but you know what?  I’m having a blast doing it.

I’m not the smartest.

I’m not the most eloquent.

I don’t use the biggest of words.

…. but that’s OK.  I am me, I know what I know, and I have the experiences that I have, which no one in the world can duplicate.

STAGE FRIGHT!

I realized it was stage fright.  Essentially, fear of the unknown, fear of failure, really – fear of fear.

Once I started creating, I can’t stop.   It’s kind of all I think about.  I have so many blog post ideas, so many podcasts planned, and I’m SUPER excited about it…

bring it on!

Podcast feed: https://fauie.com/podcast

 

Routing Messages through Kafka

I’m going through a major project with a client in regards to migrating to a Kafka based streaming message platform.  This is a heckuva lot of fun.   Previously, I’ve written about how Kafka made the message bus dumb, on purpose:   find it here. 

Building out a  new streaming platform is an interesting challenge.  There are so many ways to handle the logic.  I’ll provide more details as time goes on, but there are at least three ways of dealing with a stream of data.

The Hard Wired Bus

A message bus needs various publishers and subscribers.  You can very tightly couple each service by having them be aware of what’s upstream or what’s downstream.  Upstream is where the message came from, downstream is where it goes next.  When each component is aware of the route a message must take, it becomes brittle and hard to change over time.  Imagine spaghetti.

The Smart Conductor

A conductor travels on the train.  The conductor determines the best route while moving along the train tracks.  The conductor can handle every message, after every service to determine which service is next in line.  This cleans up the function of each service along the line but makes the conductor pretty brittle too.  The more complex the system gets, the more complex the conductor gets.  A rules engine would be a great component to add to the conductor if you choose this path.

The Map Maker

A map maker plots a route for a hiker to follow.  In our case, the map maker is a component that sits at the very beginning of every stream.  When the event comes to the map makers topic (in Kafka), the map maker determines the best route for the message to take.  Using metadata or embedded data in the event, the map maker can send the route down the chain with the event itself.  Each service can use a common library to read from its configured topic, allow the custom service to do some work, and then use the wrapper again to pass the message downstream.  The biggest advantage here is that each service doesn’t care where the message comes from, or where it goes next.   This works great for streams that are static, and the route can be determined up front.    If there are decisions down stream, then it may need a ‘switch’ service that is allowed to update the route.

What’s the best path for your application?    Have something better that I haven’t thought of yet?

 

 

 

 

 

© 2017 De-Coder’s Ring

Theme by Anders NorenUp ↑