I am a Senior Software Engineer with 12+ years of experience designing and building scalable software systems in the cloud.
In my last role at PagerDuty I was:
- a full-stack engineer; I shipped frontends and backends to millions of users
- a mentor; I supported my co-workers through 1:1 mentoring and pairing/code reviews
- a DevOps engineer; I mitigated incidents and drove down MTTR for mission-critical microservices
- a tech lead; I successfully delivered high-impact projects in collaboration with UX and Product
---
I'm looking for an opportunity to work with passionate people on large-scale, innovative projects.
FWIW, a little experimented I just ran showed me that with simple layers the cold start time of my little 3MB Go app was <100ms, using the Docker image `amazon/aws-lambda-go:1` instead took ~1500ms.
- - - -
REPORT RequestId: f905d5fe-a64e-48c8-b1f2-6535640a6f82 Duration: 7.55 ms Billed Duration: 1309 ms Memory Size: 256 MB Max Memory Used: 49 MB Init Duration: 1301.10 ms
- - - -
REPORT RequestId: 89afb20d-bc49-4d89-91f0-f1ef62ac99aa Duration: 12.20 ms Billed Duration: 13 ms Memory Size: 256 MB Max Memory Used: 35 MB Init Duration: 85.37 ms
I wrote them again a week later. Still got no response. Then I contacted the HR people on LinkedIn and got mostly rejections - but one interview, actually. So I totally agree, you have to follow-up. Didn't mention that in the article.
It would be nice to look back at a decade of blogging, but I only started like ~3 years ago. It has many, many benefits: Practicing written communication, organizing one's thoughts, build up credibility, learn things in-depth by teaching etc.
Now that I think about it, actually, publishing anything in general. Working out in the open. I often kept side project to myself. I should have just open sourced that (did that for some projects after the fact).
"This guidance is designed to help you get started with the CQRS pattern and event sourcing. It is not intended to be the definitive guide to the CQRS pattern and event sourcing. Instead, it's a journal that describes the experiences of a development team with no prior CQRS proficiency in building, deploying (to Microsoft Azure), and maintaining a sample real-world complex enterprise system as a reference implementation (RI) to showcase various CQRS and ES concepts & techniques."
Well, obviously we want to prevent stealing the HTTP session. But maybe someone steals the user's password - we can't protect the user's password for him.
So when someone from the US suddenly logs in on another continent we want to detect that. Sure they could use a proxy, but maybe. Since it's a B2B app people rarely use it out of the office.
I read eCommerce shops do it, payment providers as well. So there seems to be something to it...
"It is now possible to configure the number of concurrent requests served by each of your app's dynamic instances ..."
Wow! This is huge!
I wonder if other platforms (Java, PHP, Python) will also get this. Go is wickedly fast, starting up and instance as well as serving a request. And now that an instance scales to much more concurrent requests it even scales fantastically. Awesome.
EDIT I just saw in the documentation that Java can do this as well! Our main business runs Java on App Engine and I never heard about this ... odd.