Excerpts From a Letter to Myself

For the past 20 years I’ve had a personal tradition of taking some time on New Years Eve to write into a kind of time capsule. It’s private — just for me, an honest outpouring and reflection of where I’m at in key areas of my life because I’m not worried about anyone else reading it or what they might think. It’s an important part of my process of understanding where I’m currently at by remembering how I felt in prior years.

This year I decided to share just a few small excerpts from my entry.

Every new beginning comes from some other beginning’s end

A new year is always a new beginning in a way. I’ve had to start over in life a number of times in a variety of ways. I’ve almost gotten used to it. It’s always hard, but it’s a time of valuable reflection.

I recently found the Father Mike Schmitz podcast and his episode on Saying Goodbye, Starting Over, and Transitioning I thought was pure gold. “Change is something that happens to us. Transition is something that we cooperate with,” he says. I’m doing my best to honor what came before but make room for the beginning of something new, to learn from prior endings but be open to life’s unending possibilities.

Father Mike says this about beginnings. “The beginning itself can often be even more challenging than the ending. Everything is unknown. You don’t have your bearings. Beginnings can be so difficult that we second guess if we did the right thing. Be patient with yourself — Don’t freak out, don’t run away, and let yourself be a beginner. Beginners ask questions. Beginners don’t know automatically. Beginners make mistakes. Beginners ask for help. Give yourself permission to be a beginner, to ask questions, to make mistakes, to need help. And remember, that last place you left, that was a sad goodbye maybe, because it was home, it was familiar, it was something you were passionate about. You started off as a beginner there too. You’ve done this before, you know what it’s like. Be patient. Know that the Lord is using this right now to purify your heart, to invite you to lean in more deeply and closely with his heart , and to invite him into the beginning.”

That’s my prayer for this year.

Reconnecting with my life force

“Focus on your life force and everything else will fall into place.” – Phil Stutz, in the Netflix documentary by Jonah Hill on his therapist Phil Stutz, who said if you’re not sure what to do with your life, to focus first on your body (exercise, diet), then other people (have lunch with a friend), then yourself (just write and see what comes out). This really resonated with me, in part because I had already started down this path and already felt started to feel more optimistic because of it. While I have some plans and I know what I want out of life long term, I really just want to focus on my life force and see where that takes me.

Be like the surfer

“Be like the surfer” is kind of a private reference for me. This year Sydney participated in Surfers’ Healing, where they take autistic kids out surfing – yes actually riding waves on a real surf board (a bit of a shock to at least this east coaster who had never even seen an adult surfing in real life). I was so moved by the whole event, that so many people would give back in this way. It was such an amazing opportunity and it was all free for kids with autism. Sydney’s volunteer surfer made an impression on me. He was out surfing with her for quite a while, maybe 45 mins. They’d ride a wave in and he’d just put her back on the surf board and head out again. I don’t know why exactly it made such an impression on me. Something about the way he carried himself and her. Sydney was in a bit of a mood that morning, she was impatient and unwilling to wait, she had trouble even standing in line and my forcing her to stay in place wasn’t helping things. But the surfer didn’t seem to mind. He just worked with her and kept heading out. As her father I want to have that attitude. She might be kicking, screaming and discontent, but instead of yelling at her, telling her “that’s not nice”, I just carry on with being her father and caring for her the best I can. Just put her back on the surf board with me and head out again to try to ride the next wave.

So this short saying, “be like the surfer” is a shortcut for me to reconnect with this picture of love that demands effort, tons of patience, and sacrifice.

Evolve Or Die: AWS re:Invent 2022

AWS re:Invent is just such a great time of learning, connecting, and getting pumped up!  It’s one of my favorite weeks.  Maybe it was the nostalgia of Martin Garrix again DJ’ing the party this year – I went back and read the blog post I wrote after my first re:Invent in 2016.  That year Andy Jassy wrapped up his keynote saying that he believed the next 10 years would produce markedly more innovation than the first 10 years of the cloud. I remember feeling like that would be a tall order but 6 years later I’m still impressed with how much innovation there continues to be.

Werner Vogels talked about how the nature of the cloud is asynchronous and event driven and stressed how this is the architectural foundation for the future.  “Build systems that can evolve.  And the best way to make evolvable systems is to focus on event driven architecture.”

The serverless ecosystem was bolstered further this week with several announcements including EventBridge pipes, which lets you stitch events together with little or no code, similar to how we “pipe” a chain of commands together on the terminal. “Only code as a last resort” was a key takeaway from a session on this. Lambda should transform not transport, use configuration wherever possible.

It changes the game to know that you can build something that is both amazingly affordable and at the same time built to handle massive levels of scalability.  Leveraging event driven serverless architecture we’re now in a position to develop serious enterprise grade apps that cost basically nothing when dormant, can handle thousands of users on lunch money, and are designed around elasticity for future growth.  That’s empowering to me, and once again I left re:Invent this year inspired to go build something!

Introducing Riley & Bot: Jobs For Robots And Jobs For Me

I’m excited to announce the release of Jobs for Robots and Jobs for Me, an illustrated children’s book about artificial intelligence (AI) and the future of work.

I wrote this book because I wanted to introduce to children and parents the notion that AI will be capable of doing much of our work by the time the kids reading this book “grow up” and are ready to get a job, and because of my daughter Mackenzie’s interest in books on jobs (she wants to be a veterinarian). Many people seem to underestimate the impact and timeline that AI will have on jobs and our economy. It’s hard enough to believe that autonomous vehicles aren’t far away from displacing millions of transportation workers. It’s even more difficult to think that you might go through years of graduate school only to find that your area of discipline is performed better by AI. It’s a tough message. There is so much change coming so fast that it is hard for anyone to believe. We’re all children it seems when it comes to the understanding, appreciation, and fear of the power of AI.

I don’t try to paint a rosy picture just because it’s for kids. I think they are due a glimpse of how jobs will likely shift to robots and AI in the future. This book is real about the extent to which AI may largely displace jobs ranging from truck drivers to doctors, and even artistic and creative work will not be exempt.

While I playfully point out that there will be new jobs created which don’t exist yet, the world I hint at is one where AI will be better than us at many tasks and the owners of the AI are set to receive huge rewards while the rest of us struggle to shift into work still better performed by people. The story is a mixture of surprise, despair, excitement and hope, because it’s not a fairy tale, it’s a thoughtful depiction of the world I truly believe our children will find themselves in. We must reinvent ourselves as the landscape of work is reinvented before our eyes. Ultimately I hope for this book to be a conversation starter, and to raise awareness with parents and children so we can be best prepared for whatever is coming.

The book is available in softcover, hardcover (coming soon), and e-book at Amazon.

Wisdom from Will

Book Review: 'Will,” by Will Smith with Mark Manson - The New York Times

When you read someone else’s story you get the benefit of wisdom it took them their whole life to acquire.  It’s one of the reasons I love biographies.  I loved Will Smith’s new book, I couldn’t recommend it more.  It was entertaining and also contained wisdom that really resonated with me.  Below are all his words, I have no need to add to it.

The thing I’ve learned over the years about advice is that no-one can accurately predict the future, but we think we can.  So advice at its best is one person’s limited perspective of the infinite possibilities before you.  People’s advice is based on their fears, their experiences, their prejudices and at the end of the day their advice is just that, it’s theirs not yours.  When people give you advice, they’re basing it on what they can do, what they can perceive, and what they think you can do.  But the bottom line is, while yes it is true that we’re all subject to a series of universal laws, patterns, ties and currents, all of which are somewhat predictable, you are the first time you’ve ever happened.  You and now are a unique occurrence of which you are the most reliable measure of all the possibilities.
– Will Smith, Chapter Five: Hope

We punish ourselves for not knowing.  We always complain about what we could and should have done.  And how much of a mistake it was that we did that thing, that unforgivable thing.  We beat on ourselves for being so stupid, regretting our choices and lamenting the horrible decisions we make.  But here’s the reality – that’s what life is.  Living is the journey from not knowing to knowing, from not understanding to understanding, from confusion to clarity.  By universal design you are born into a perplexing situation, bewildered, and you have one job as a human – figure this shit out.  Life is learning.  Period.  Overcoming ignorance is the whole point of the journey.  You’re not supposed to know at the beginning.  The whole point of venturing into uncertainty is to bring light to the darkness of our ignorance.  I heard a great saying once.  Life is like school with one key difference.  In school you get the lesson and then you take the test.  But in life you get the test and it’s your job to take the lesson.  We’re all waiting until we have deep knowledge, wisdom, and a sense of certainty until we venture forth, but we’ve got it backwards.  Venturing forth is how we gain the knowledge.  
– Will Smith, Chapter Six: Ignorance

The universe is not logical.  It’s magical.  A major aspect of the pain and mental anguish we experience as humans is that our minds seek and often demand logic and order from an illogical universe.  Our minds desperately want shit to add up but the rules of logic do not apply to the laws of possibility.  The universe functions under the laws of magic.
– Will Smith, Chapter Ten: Alchemy

An alchemist is a spiritual chemist, a master of transmutation.  The great feat of an alchemist is that they can do the impossible.  They can turn lead into gold.  This concept erupted in my mind – the ability to take anything that life gives you and turn it into gold.  Gigi could take the last half glass of welch’s grape juice and mix it with the last swallow of dole pineapple juice, throw in some kool aid packets, dice up some lemon and the other half of the orange she was just eating and swirl it all together with a blast of canada dry ginger ale, freeze it, and hand you the best damn popsicle you’ve had in your life.  This was after you’d looked in the refrigerator five separate times and each time told her there was nothing in there.
– Will Smith, Chapter Ten: Alchemy

Change can be scary but it’s utterly unavoidable.  In fact impermanence is the only thing you can truly rely on.  If you are unwilling or unable to pivot and adapt to the incessant fluctuating tides of life, you will not enjoy being here.  Sometimes people try to play the cards that they wish they had instead of playing the hand they’ve been dealt.  The capacity to adjust and improvise is arguably the single most critical human ability.
– Will Smith, Chapter Eleven: Adaptation

“Do not get comfortable with your back on that canvas!”, he said.  “You fight how you train.”  You fight how you train was one of Darrell’s central axioms.  “You do everything how you do one thing”, he’d say.  Darrell didn’t want me to get comfortable with my back on the canvas in case I ever got knocked down.  He wanted lying down in a boxing ring to feel utterly foreign to me just in case I ever found myself lying down in a boxing ring.  His position was dreams are built on discipline, discipline is built on habits, habits are built on training, and training takes place in every single second of every situation of your life.  How you wash the dishes, how you drive a car, how you present a report at school or at work.  You either do your best all the time or you don’t.  If the behavior has not been trained and practiced then the switch will not be there when you need it.  “Training is for the purpose of habituating reactions to extreme circumstances”, Darrell said.  “When situations get hot you can’t rely on your thinking mind.  You must have habituated reflexive responses that kick in without the necessity of thought.  Never detrain your killer instincts.”
– Will Smith, Chapter Sixteen: Purpose (Darrell Foster who trained Will to portray Muhammad Ali)

Surrender had always been a negative word for me, it meant losing or failing or giving up.  But my burgeoning relationship with the ocean was exposing that my sense of control was actually an illusion.  Surrender transformed from a weakness word to an infinite power concept.  I had a bias toward action – thrusting, pushing, striving, struggling, doing.  And I began to realize that their opposites were equally as powerful – inaction, receptiveness, acceptance, nonresistance, being.  Stopping was equally as powerful as going.  Resting was equally as powerful as training.  Silence was equally as powerful as talking.  Letting go was equally as powerful as grasping.  Surrender to me no longer meant defeat.  It was now an equally powerful tool of manifestation.  Losing could be equal to winning in terms of my growth and development.  I began to understand a perplexing phrase that Gigi used to use – “let go and let God”.  That had always seemed wrong to me.  It felt like absolving yourself of your responsibilities, like something that people say when they are too lazy to do what’s necessary to build the life they want.  But all of a sudden it took on new and magical meaning.  There is an energy that is at work while you were asleep, the energy that fires the sun, that moves the ocean and that beats your heart.  You don’t have to do everything.  In fact most of the things that get done you didn’t have anything to do with them, and actually it’s a great thing that you were asleep because if you had been awake you probably would have messed it up.  Then a new wording of Gigi’s axiom came into mind, not just let go and let God, it’s let go and let God work.  The surfer and the ocean are a team.  The mountain and the climber are partners not adversaries.  The great river is going to do 99% of the work.  Your 1% is to study it, to understand it, to respect its power, and to creatively dance within its currents and its laws.  Act when the universe is open and rest when she’s closed.
– Will Smith, Chapter Twenty: Surrender

8 Quotes That Shaped My Worldview

silhouette photography of person

A worldview is a collection of attitudes, values, stories, and expectations. It represents our most fundamental beliefs and assumptions about the world around us. “As such, worldviews play a central and defining role in our lives. They shape what we believe and what we’re willing to believe, how we interpret our experiences, how we behave in response to those experiences, and how we relate to others”, says James Anderson of Ligonier Ministries.

These thoughts have greatly shaped how I see the world.

“The fool doth think he is wise, but the wise man knows himself to be a fool.” (Shakespeare)

It’s easy to get caught in the trap of thinking we know what is best for ourselves, for others, and the world. The best we can do is have some humility the next time we catch ourselves thinking we know the way. It’s okay not to have all the answers – better than okay. Acknowledging this may be our only chance at wisdom.

“Security is mostly a superstition. It does not exist in nature, nor do the children of men as a whole experience it. Avoiding danger is no safer in the long run than outright exposure.” (Hellen Keller)

There is no “safe”. Everything you have could be gone in a minute for reasons beyond your control, whether you play it safe or not. If you knew that savings account you’ve been contributing to for so many years would be wiped out when you needed it, would you regret not having taken some risks along the way? That is not to say to be reckless, but being risk averse doesn’t pay the life long dividends you think it does, and likely steals the best version of yourself away.

“You shouldn’t hesitate to modify your perceptions to whatever makes you happy, because you’re probably wrong about the underlying nature of reality anyway.” (Scott Adams)

Part of why we’re so hard on ourselves is we think we understand the world. We think we know its rules and limitations, and our own potential or lack thereof. But what if we’re wrong about all of that? What if we’re just not capable of understanding the true nature of our world or how others perceive us?

Scott continues, “If I had to bet my life, I’d say humans are more like my dog trying to use psychic powers on me to play fetch than we are like enlightened creatures that understand their environment at a deep level.” This worldview helps me not to take things so seriously. I believe there is more magic, wonder, and possibilities both within the universe and within ourselves than we are capable of seeing or understanding.

“Believe those who seek the truth, doubt those who find it.” (Andre Gide)

Confirmation bias is an inescapable part of humanity. We don’t seek the truth so much as we seek out things that support the conclusions we’ve already made. It’s sad that it takes so little to form an initial opinion and that all information seen after developing this opinion is seen as either “right” and in support of our early conclusion, or “wrong”. This is true even in the field of data science where we can masterfully manipulate the data into telling whatever story we want. And just being aware of confirmation bias doesn’t make us immune to it. I hope to be as open-minded to concede to the possibility that everything I know might be wrong, but I’m probably too entrenched in my views to truly be that objective.

“I find it helpful to remind myself that every human is a mess on the inside. It’s easy to assume the good-looking and well-spoken person in front of you has it all together and is therefore your superior. The reality is that everyone is a basket case on the inside. Some people just hide it better. Find me a normal person and I’ll show you someone you don’t know that well. It helps to remind yourself that your own flaws aren’t that bad compared with everyone else’s.” (Scott Adams)

Enough said.

“Be, Do, Have.” (Robert Kiyosaki)

Before you can DO what is necessary to HAVE the life you want, you must BECOME the person who would do those things. The order is very important. I used to think if you do certain things you can have what you want and that will make you into the person you want to be. But having things doesn’t make you into anything, nor would you likely do enough to have what you want without first becoming the person you need to be.

The “be” is a flywheel. If you’re a _____ kind of person, you can’t help but do _____, and if you do that you can’t help but have _____. It’s automatic. You can’t help but do what you do because of who you are. This can work to your benefit or against it, depending on what your “be” truly is.

“Life will give you whatever experience is most helpful for the evolution of your consciousness. How do you know this is the experience you need? Because this is the experience you are having at the moment.” (Eckhart Tolle)

Have a difficult person in your life? I believe this is a gift, handcrafted and placed exactly into your life so that you can learn from it. Sometimes it can take years to understand the lessons from the difficult things in your life, maybe a lifetime, and life will keep serving you the same kind of lesson until you get from it what you need.

“For even a few moments at a time, being aware of what is arising, gives us the possibility to make a choice.” (Joseph Goldstein)

I’m not so sure we actually have free will, or maybe that we are not really conscious the vast majority of the time. So rarely are we present enough to make a choice we could truly call our own. The best we can do is focus on the present moment, notice our own thoughts as they arise and maybe instead of just reacting and following our program, choose if those desires are really from our innermost soul.

See also Why You Probably Don’t Have Free Will.

Things That Trigger Me (Well, Tech Related)

After I left my last company, one of my teammates shared with me a list of things she had been keeping about me in the Notes app in her phone called “Things that trigger Doug”. It must say something about me that someone would keep such a list. Anyway it made me laugh! You’ll only appreciate this if you work in tech. I give it to you unedited:

  • Writing shitty code the first time with the excuse of “trying to get it to work” / hard coding shit to make it work
  • White IDE theme
  • Stealing his phone
  • Waiting in a line for 2 hours
  • When you don’t believe in containers
  • Windows 7 in 2019
  • Using private chats instead of public Slack channels
  • Agile words
  • People who wait to write their Dockerfile until the last minute /don’t dev in a docker container
  • People cheating in the step challenge when he runs 14–16 miles a day
  • Designated CAB meetings /calling releases “emergency” or “off cycle”
  • Notepad++
  • QA tester boxes / manual testing
  • Ad blocker. Support the creators!
  • Naming things poorly
  • End to end tests
  • People calling stuff a blocker when they aren’t blocked by shit
  • Iframes
  • Wasting money in the name of frugality
  • Putty
  • Putting “Personal Interests” on your resume

10 Rules For Building Better Internet Applications

blog_headerIf you’re working on an application that’s been around for a while, has lots of usage and several different teams working on it, there’s a good chance it’s a dumpster fire. It happens to the best of us. Building software with real customer adoption is messy business. While there is no one size fits all, these are my opinions on building more reliable, scalable, and maintainable Internet applications.

1. Go All In On One Cloud

Pick the leading cloud provider that makes the most sense for your team and go all in. Don’t miss half the benefit of the cloud by limiting yourself to the lowest common denominator between cloud providers, which is basically just VMs. This is folly anyway as it is nearly impossible to build an application natively in the cloud without tentacles into proprietary resources from that provider. Trying to be on the light end of the lock in spectrum is not worth the trade off you’d be making in lost productivity and reliability.

2. Forget About Servers

Use containers and/or serverless for 100% of your dev, stage, and prod environments. There is almost no reason to use VMs directly for any new development. While containers and serverless have their own set of challenges they are an order of magnitude better than using configuration management (Ansible, Chef, Puppet) and are your only hope for getting your dev team to participate in DevOps, which is necessary to scale development of a cloud native application.

3. Commit Wholly To Infrastructure As Code

Don’t take shortcuts that question your ability to stand up the application from source in the future. Make defining your infrastructure as code a requirement, not a nice to have. This applies to your infrastructure primitives (e.g. building blocks directly in your AWS account) as well as any third party tools or services you may want to integrate with. If it can’t be brought to life entirely from source code, you should seriously consider an alternative that can. Your application code needs a specifically configured environment to run in. Setting up that environment by hand is like writing a program, deploying it to production, then deleting the source code. Let’s not even talk about that install guide document you pretend is accurate and up-to-date.

Your first line of code should be your Dockerfile, or maybe your serverless yaml or your Terraform. The point is, start with your infrastructure code, at least enough to define your immediate development environment, which becomes the blueprint for production. Store your infrastructure code with your app code, lock step with the application in the same git repo with each microservice. You should be able to clone a git repo from any computer, build the Docker image and immediately start working on it, no matter what language it’s written in or dependencies it has. “It works on my machine” is the joke of the last generation of software development. Think of your machine as a text editor and a Docker engine.

4. Embrace The Ephemeral

I think it’s helpful to think of your code running on a “server” that didn’t exist 5 minutes ago and won’t exist 5 minutes from now (or maybe seconds, or milliseconds). If you haven’t noticed, in the cloud they aren’t even called servers anymore, they’re instances, hinting at their proper use lifespan.

Never write out any state to local disk volumes. Pretend your environment doesn’t even have a local disk. Expect instances of your program to terminate abruptly due to auto-scaling or chaos experiments. Your operations need to be idempotent, and anticipate retries. You need good logging and usage metrics, which your application must be deliberately broadcasting. Throw away your ssh keys and keep the telemetry mindset of your application running on an inaccessible remote location.

This forces the issue of immutable infrastructure. It makes no sense to modify or “patch” something that has a lifespan of milliseconds to minutes. Change is always by terminating the existing resource and replacing it with a new one with new settings.

5. Use Managed Services Wherever Possible

Building and operating clusters of anything isn’t providing business value or helping you to quickly iterate. Wherever possible, skip all that undifferentiated heavy lifting and use a managed service.

Installing a database server for example, on a single server for development isn’t so hard, but doing it in production in a way that is highly available is another story entirely. You have to setup an auto-scaling configuration where nodes can launch and rejoin the cluster, setup and test failover and restore for your HA configuration, and setup and test all the associated monitoring and alarms. It’s easy to get something wrong here and since you’re usually in the data layer, these are costly mistakes. And since our dev and stage environments need to match our production environment exactly (apart from instance size), the easy single server installation isn’t acceptable in any environment. Maybe this would be manageable if we were doing this once for one huge database server, but in a microservices world each with their own isolated data layer, it’s just not practical to self manage with dozens of services. Recalling the earlier rule about bringing everything to life entirely from infrastructure code, usually the only way to accomplish this without a herculean effort is to use a managed service. If you’re insisting on installing everything on EC2 yourself you are missing half the benefit of the cloud.

6. Testing Should Make You Go Faster Not Slower

Testing should give you rails so you can speed, not gates to force you to come to a stop. Your tests (all of them – unit, integration, load, front end) should be a completely automated part of your build and deploy pipeline, and like your infrastructure code, should reside in the same git repo as the component they are testing. The same integration tests should run against all environments, especially production, which is the most important environment to test because it is the only one your customers actually see. This means you need to use test accounts in your real databases, your testing can’t rely on starting from a fresh database each run, which isn’t feasible in production, and demands exclusive use of an environment for testing, which obviously doesn’t scale. This requires a close partnership with development, it simply won’t happen if you treat QA as a siloed activity.

Testing should share the microservices mindset – when we replace a pipe in the basement, we don’t always need to reinspect the whole house including the windows in the attic. Testing is critical, but we don’t want testing at any cost. Don’t let outdated testing practices be the weak link in your agile process.

7. Always Be Deploying

Because I think this one is so important, I’m going to borrow the sentiment from the infamous Glengarry Glen Ross, “Because only one thing counts in this life. Get [the code deployed to production]! You hear me you ***** *****! A, B, [D]. A – always, B – be, [D] – [deploying]. Always be [deploying]. Always be [deploying]!”

The more time that passes between deployments, the higher your integration risk, and the greater chance you are blocking another service which you are a dependency for. This is exactly why we do CI/CD in development. While I’m not saying you need to do continuous deployment in production, the same risks accumulate as time goes on so you want to keep the change delta as low as possible. Plan on deploying every sprint. Most deployments are back-end services with minimal to no customer facing aspects, so this doesn’t necessarily mean visible UI changes all the time.

Each microservice should be independently testable and deployable. When working on a feature that spans multiple microservices, deploy each one as soon as it is ready, don’t squirrel them away to deploy all at once in some blaze of glory.

So put that coffee down, coffee is for deployers!

8. Write Your README Before Writing Any Code

As the saying goes, “If you don’t know where you’re going, any road will take you there.” I love the Amazonian practice of starting a new project or feature by first writing a press release announcing it. I think that causes you to think bigger and to go into the work with a more clear picture of the most important parts of what you’re building. Perhaps the microservice equivalent of that is writing your README first. Give a couple sentences about what the thing does. Show usage examples demonstrating the main interfaces. Show examples of how to build, test, and deploy it. Do this first, in the README in your git repo, not last in some external document management system.

And for the love of God, before any code is written, think about how you’re naming things. Nothing shows lack of thought about how your service fits into the bigger picture of your ecosystem of services like giving it a vague or misleading name. Renaming things seldom happens, or is really expensive to do later.

9. Open Source From The Beginning

Even if you don’t want third party contributions, I think open sourcing your project reinforces a few helpful perspectives. First you are forced to handle secrets appropriately, which makes it a lot easier to get a short term consultant involved, because you can actually share your code base without worrying about changing the secrets later (let’s be honest, doesn’t always happen). Open sourcing your project may also inspire confidence from your customers about the longevity of your platform and inspire the best from your developers who will hold themselves to a higher standard knowing their work will be on display.

More importantly, it serves as a constant reminder that while it takes valuable skill to produce the source code, it has no intrinsic value and can be easily duplicated. I know this is a difficult pill to swallow when you’re spending boatloads of money on development but it’s the truth. Your value is in your data set, relationships, reputation, and execution.

At least look to open source components of your application which may be general use tools, or with a small amount of additional thought could have a general use interface rather than being specific to your application.

10. Iterate on Customer Experience

Andy Jassy ended his 2018 AWS re:Invent keynote with some remarks which encapsulates what this is all about.

“For any of us who are trying to build long standing sustainable businesses, which is hard, the most important thing by far is to listen really carefully to what your customers want from you and how they want the experience to improve, and then to be able to experiment and innovate at a really rapid clip to keep improving the customer experience. That is the only way that any of us will be able to survive over a long period of time. That’s what you should care about, giving your builders the most capable platform and allow them to keep iterating on that customer experience.”

While of course he’s suggesting that AWS specifically be the foundation of that platform, the sentiment rings true, and that’s what all of this is ultimately about, investing our resources iterating on customer experience, and not get bogged down with boring IT stuff.

Super Powers: AWS re:Invent 2016

Amazon knows how to throw a party. They hired the best DJ in the world, literally – Martin Garrix. The re:Invent Party was an experience I’ll never forget. Walking in, you are handed an activity map, showing the locations of the digital lounge, beer garden, dance floor, and play zone including a laser dome, ball pit, bubble soccer, climbing wall, and a labyrinth. But once I got to the DJ area, I was mesmerized.  I stood in the crowd and soaked in the music, the lights, and the special effects. It was truly a performance. Even though I traveled alone and didn’t know anyone there, I felt connected, surrounded by thousands of other like minded people celebrating at this amazing event.  AWS CEO Andy Jassy captured the sentiment best saying simply “it is awesome to be here.”

The conference was sold out at 32,000 attendees and occupied most of the Venetian and the Mirage resorts.  Everywhere you went it seemed like Las Vegas was invaded by swarms of cloud enthusiasts all wearing the black and blue AWS hoodie given to us on our first day.  Fredric Paul from New Relic put it well saying “The whole event has the palpable buzz of a celebration of a successful, growing industry that feels like it’s on the right side of history.”

The theme of Andy Jassy’s keynote was that AWS gives you super powers, and I think it’s true. You have access to essentially infinite resources. As a single developer you can build something over the weekend that you can deploy globally, that can auto scale to handle any amount of volume, store any amount of data, and initially cost next to nothing.  Want to cut your teeth on a 128 CPU server with 2TB of memory?  Spin it up right now, it’s yours for $13.34 per hour.  Where else would most of us ever even have access to a machine like that?  How about a fleet of them on the spot market for up to 90% off?  Need to accumulate 100GB of storage per day?  No problem, write it out to S3 for just $0.03 per GB per month, and know you’ll never run out of storage space.  Werner Vogels, CTO of AWS put it this way – “One of the things the cloud has done is democratize access to technology power.” Just knowing that I can affordably access any resources I need challenges me to tackle something of scale.

Better yet, as Jeff Lawson, CEO of Twilio, astutely pointed out, “you don’t get points for using servers, you only get points for serving users”.  With serverless architecture, you can put together entire solutions on inherently scalable building blocks that can serve millions of users, but only cost as much as a Starbucks coffee until it starts to get some traction. The cloud really has given us super powers.

Jassy wrapped up his keynote with a few words on the next 10 years. Because AWS has grown so substantially in its first 10 years, would the the next 10 will have less invention? “I believe the next 10 years will have markedly more innovation,” Jassy said.  Apparently, the cloud is just getting started.  Instead of debating wheather companies would use the cloud or not, Jassy said “They will spend all their time using the cloud and its massive capabilities to build new business that we never imagined before.” He continued saying “This is a world that I want to live in. And this is a world that I think is very exciting to everyone in this room.” I had a blast at re:Invent, and left pumped up and ready to go build something.

DevOps, Because We’re Not In Kansas Anymore

DevOps is one of those things that are hard to wrangle down to a definition, and if you’ve read anything on the topic you probably didn’t walk away with a concrete understanding of what it is.  Most definitions seem incomplete if not even a little misleading. In particular, the main thing you hear is that DevOps is about increased collaboration between dev and ops teams. However many apps in the cloud are supported entirely by the dev team, with minimal or no ops involvement, but still very much have need for DevOps. In this context, DevOps is more about new tools, methods and practices of building and running apps in the cloud.

“I Would Spend 55 Minutes Defining the Problem and then Five Minutes Solving It”
Albert Einstein

Okay Einstein, let’s start there. The problem is we need to run and continually update our software in a scalable, reliable, and affordable manner. For this we look to the cloud. But running applications in the cloud is fundamentally different, and to do it effectively we need to adapt to a new way of doing things.

DevOps is the “stuff” that solves that problem.

So what is DevOps? The predominant, and tip of the iceberg answer is that DevOps is about delivering software faster, which in turn is about automation — having a robust continuous integration and testing process, automating the deployment process, and even automating the creation of infrastructure. It’s getting from “I just finished writing code” to getting it into an environment to test.

Before the cloud, there was often a sense of permanence and consummation in both the infrastructure and the application itself. The new reality is that both are ephemeral, subject to constant change and updating.

We do DevOps because we’re not moving into a house, we’re getting on a treadmill.

So sure, DevOps is about building a deployment pipeline, but that’s really just the beginning.  It’s the “day two” stuff, the operations, the scaling and monitoring, that I think is often overlooked as part of DevOps. To consider why we need new tools and methods, let’s reflect on what many of us were doing prior to the cloud. We had been running our applications on a fixed number of servers which we spent weeks to procure and configure, mostly by hand with little to no documentation or automation. We gave these servers cutesy names like they’re pets. Deployments often involved scheduled downtime. Servers were too often in a single geographic area.

Not surprisingly, a first endeavor to deploy in the cloud often involves as little adaptation as possible — we’re doing it a lot like we used to “back on Earth” by hand configuring servers, imaging them, and launching VM’s from those images. So we’re technically “in the cloud”, and there are some powerful benefits already, but we’re only halfway to solving our problem.

In the cloud we’re deploying on to VM’s or containers which may launch and terminate in as little as a few minutes. And they might be behind a load balancer and firewall that was just created a moment prior with an API call.  Scaling is elastic, measured, and operates automatically based on real-time conditions.

Launching an application into the cloud is a lot like launching a satellite into space.

Your app is running on instances on the east coast, then it’s on the west. Next time you look it might be in Asia. Getting information from it is like telemetry.  It’s a helpful mindset to consider servers in the cloud as being inaccessible remote locations because it reminds you to plan ahead what stats, data, and logs you want to get back from it and build an automated means of transmitting that data to a central place. You can’t wait until something goes wrong and then expect to ssh into the server and look around, it may well be terminated by then. In fact, just to remind you how short lived they are, we don’t even call them “servers” anymore, they’re “instances”.

Before cloud architectures, the assumption was the server was a “going concern”. It was going to be there and continue to operate unless something catastrophic happened. With cloud, this assumption is turned on its head. For reasons like auto-scaling, health check failure, or even getting your hourly price out bid in the spot market, your instance could be terminated in a moments notice. All of this means we now have to build our apps in a way that is tolerant to sudden shutdown and can resume by another node. We can’t even rely on short term storing of any state in memory or on disk.  Consider them literally as they are called, “compute instances”.

We have to have a strategy for health checking our applications. Sure we’ve had monitoring before, but now our infrastructure will automatically terminate any instances that fail to meet the health check requirements — and if you’re not careful, can terminate your entire cluster for something that might have been a momentary hiccup, leaving you completely down for 5 to 10 minutes until new VMs boot up.

These are among the many fascinating DevOps problems you will need to think through and solve as you devise your own way of deploying and scaling apps in the cloud.

All of a sudden you realize you’re building your own platform.

A more complete picture is that DevOps isn’t just automating deployments, it’s building or updating applications to 12 factor apps with scaling and ephemerality in mind, which implement your established health monitoring and logging standards, and building a pipeline and set of practices for deploying and operating those apps.  We don’t just get that out of the box with our IaaS provider.  And so I think a lot of the work which is currently done out of necessity under the umbrella of DevOps will increasingly be provided by platforms that sit a layer on top of IaaS.  Knowing how much work goes into building all of this on your own, I believe that PaaS is the future, for the same kinds of reasons why IaaS has value over building your own data center.

We need DevOps because we need the cloud, and the reality is that DevOps is just necessary to deploy and operate modern apps in the cloud, weather you are doing all of it yourself or leveraging a platform for some portion of these functions.

UX So Bad It Just Might Kill Someone: Audible’s New Clips Feature

Even with the recent rise in focus on user experience (UX) testing, I think the practice in general is frightfully under invested in. I don’t have unreasonably high expectations of products, but sometimes the UX is so bad that it makes me literally shout out loud in anger at the company who made it. Such was the case from my experience with the new Audible app this morning. I have listened to hundreds of books with Audible over the past several years. I’ve recommended Audible along with the practice of using your commute to learn to anyone who’ll listen. Lately I’ve been listening mostly to podcasts, so I didn’t notice the recent changes to the Audible app until this morning.

They’ve replaced “Bookmarks” with “Clips”. Sounds harmless. In fact, the clip feature can be useful, if say I’m listening to a book while lying back on a beach chair by the ocean where I can casually take the time to mark the beginning and end point of my clip and edit it to make sure I remove any unintended words. But like most people, I listen to audio books mainly in my car, and you can’t use this feature while driving without seriously risking your life. I can’t bother with marking the beginning and end of my clip you *$$@#!#@$#  $#!@%, I’m driving! I tried to use a clip like a bookmark but it resulted in making a large clip from the beginning of the book to the point where I wanted to bookmark.

It’s labeled in the app “Clips and Bookmarks”, seemingly implying think the plain old bookmark functionality is still there somewhere if I can just find it (it’s not).  It was dangerous enough using bookmarks while driving, but clipping is completely out of the question. It’s a shame because I really value my bookmarks.  But this feature is just too dangerous to use while driving.  I guess I will have to make sure the important points sink in the first time.  I just expect more from large companies like Audible (Amazon), in part because I know it’s likely that there’s a team of people who work there whose focus is UX.

I know, I’m not supposed to be using my phone while driving in the first place.  But I’m not sure how realistic that is as a hard rule.  This isn’t exactly texting.  I think certain apps like music, audio books, and GPS navigation, are meant to be used in a car and it’s unrealistic to expect zero user interaction while driving.  If these apps are made with the expectation of light use while driving, they should be no more difficult to use than operating the built in car radio or air conditioning.