DEV Community

Serverless Chats

Episode #32: Customizing Serverless for Custom Ink with Ken Collins

About Ken Collins:

Ken is a Staff Engineer at Custom Ink focusing on DevOps & eCommerce architectures with an emphasis on emerging opportunities. Custom Ink is approaching its 20th year in business and is entering its second phase of Cloud adoption where he helps a growing engineering team succeed using AWS-first well-architected patterns. Ken lives near Norfolk, VA and organizes the area’s Ruby User Group.


Transcript:

Jeremy: Hi, everyone. I'm Jeremy Daly and you're listening to Serverless Chats. This week I'm chatting with Ken Collins. Hi Ken. Thanks for joining me.

Ken: Hi Jeremy. Thanks so much for inviting me.

Jeremy: You are a Staff Engineer at Custom Ink. Why don't you tell the listeners a bit about yourself and what Custom Ink does?

Ken: Yeah, I think maybe first I'd like to say thank you for inviting me to the podcast, really great to be here. I definitely would like to think that it's not because we both have 38-inch, identical Dell Curved Monitors. A very exclusive club.

Jeremy: It is an exclusive club.

Ken: Sure. Custom Ink, let's see. I'm a Staff Engineer, I focus mainly on the eCommerce side. Custom Ink is about 20 years in business. And, I think we're probably only unique in the fact that we're a successful company that has a long history with Rails.

 We've been going along for those 20 years, a lot of those years have been with Rails. And, we've sort of completed a lift and shift into the cloud since about 2017. And, we've had some interesting things to do with cloud adoption or adoption of serverless and all things basically AWS.

Jeremy: And, what about yourself? What's your background?

Ken: Well, let's see. I'm a self-taught programmer. Used to be a designer, used to be a marketing director. I think at one point in time I was the author for the act of record SQL server adapter. So, represented the Ruby community and Microsoft when they first started doing their transition to open-source.

And, I think I really love open-source. I'm focusing mainly on retooling my personal career and learning everything about AWS. And, that started about last year. And, doing everything I can at Custom Ink to sort of sell the serverless story, and to get more cloud adoption within the organization.

Jeremy: Very cool.

Ken: Thank you.

Jeremy: All right, so I wanted to have you on today because I've had a number of guests. And, we talk about serverless in theory all the time. And, we have all kinds of great ideas of architectures. And, I mean we get into some of the practical stuff. But, the hands on piece of it, and how companies like Custom Ink are actually getting their hands dirty. And, doing the work to figure out how to implement it. Every one of those stories is different, and I just really love the story that Custom Ink has. I think I saw a testimonial on the AWS site about sort of how you started with it.

I want to get into that because I think that's really interesting for people to hear how other companies get started with serverless and Lambda. And, how they start adding that. And again, you've gone through the experience of the lift and shift. I know you have some interesting microservices stories that I think would be great to hear about. But, let's start with that, let's just start ... you started moving to the cloud, you did the lift and shift thing. And, I'm assuming those were mostly monolithic applications, so what was the next step for Custom Ink?

Ken: Yeah, I think our story arc, maybe about 2014 was key sort of monolith. We had a very traditional big Rails frontend and a big Rails backend that sort of shielded us from a legacy Java backend. And, at that point in time, and we still didn't finish our cloud sort of migration until 2017. Which, is basically just a bunch of EC2 instances.

At some point in time in 2014, I think that's when Lambda came out. And, there was a lot of buzz around microservice architectures first. And, we even had a business unit that had started off in 2014. That we sort of gave them this majestic monolith, and the business unit decided to immediately retool that entire monolith into microservices first. It was just the hot thing to do in 2014.

Jeremy: Sure.

Ken: And, I believe that took about a couple of years to really fail miserably. In fact, everything that they went to engineer on, just breaking things apart. Eagerly because that was the architecture to do, versus the success of the company driving that microservice architecture all rolled back. All changed, eventually we got merged back into the core business line. And, that really sort of affected, I think a lot of the corporate memory about how we approached microservices.

Jeremy: Sure. Then after you sort of had this epic failure. And again, I think this is nothing against Custom Ink. Because, I think this happens to a lot of people, who try to do that second version syndrome and say, "we'll just take our existing application, break it up into smaller pieces and everything's going to be great." That typically doesn't work. Sometimes it does, but most of the time I don't think it does. Then you shifted to this idea of a kind of using Lambda functions and serverless in general really to start splitting off, you actually started more with DevOps tasks, right?

Ken: Yeah. I think there has always been a little bit of AWS Glue. I call it, when I look at Lambda I've sort of from my perspective today I put them into three buckets. AWS Glue is when you're just sort of glueing things together, maybe you're popping Kinesis Streams off of a DynamoDB. Or, you're just doing some little small tasks, maybe scheduling the shutdown of EC2 instances. Then there's the sort of microservice architecture of where I think a lot of people have their head space around Lambdas. And, then those are more sort of larger applications.

In, 2017 we had a brilliant engineer named Hunter. Who, took a key part of our design architecture and that really needed to come off of a Rails app, and ImageMagick. And, put it into a Node-based Lambda. And, that's what our customer testimonial on the Lambda product website is about. I think we had 90% in cost savings. Of course, we got the scaling up and the scaling down feature. And, I think starting in 2017 past that 2014 sort of failure story. We really got a good idea of what Lambda could mean for us, from a microservice perspective. And, it was all about the cost savings. And, basically breaking apart a key part of our infrastructure, around our design lab. And, pushing that just to Lambda. I think that's a traditional what they call sort of a North South client. It sits directly where we're exposing that microservice as a frontend, of graphic application to the design lab.

Jeremy: Yeah. And, I think that's a great strategy too. I mean first starting off getting that confidence with Lambda. And, being able to use it for things like you said, shutting down and spinning up those instances. And, using it for those peripheral sort of work cases or workloads, I think is really interesting. But then, that was I think the right approach. Where, and in the end I think this is why you had some success with this is; you took one specific piece of functionality or one sort of bounded context. Which was your graphic conversion system. And said, "we're going to build this as its own separate standalone thing." And then, how did that kind of integrate back into the rest of the application?

Ken: I think from an integration point of view, it really doesn't integrate at all. Other than what you're just calling this one service and you're offloading certain paths from one application. The way that it sort of fit in with our architecture is that, we would see more of these opportunities when breaking key parts of Rails applications outward. And, just converting very small parts of them into Lambda. Another good example that we did is our catalog application was a Rails application. And, it was still pulling S3 images right from the Rails app. It was also another application that was a key API for a lot of product information. Hitting that Rails application with s3 io eventually made the API less performing.

You found you had to scale a small part of it to make the whole better. And, we just sort of over the next year just sort of reapplied that pattern. What needs to come out of an application? What needs to be more performing? And, just pop it out. We let success define the lay lines of the architecture.

Jeremy: You go through the microservices exercise, you start building out these other components. How did you kind of go from lift and shift through to microservices. Then to using Lambda for these sort of side jobs or whatever. And, then moving into sort of this idea of full-stack serverless?

Ken: Yeah, that's a great question. I think full-stack serverless is a term that I sort of popped up on. I've totally co-opted it from Nader Dabit's Amplify work. And, the idea of sort of came to me when one of our engineers, one of our senior engineers. Looked at these different microservices that we typically had in Node. And, each one was very unique. Sure you would have like it would be on Lambda, but there was no sort of convention on how might your Pojos, your plain old JavaScript objects might look. How you might do routing, et cetera. And, he asked if there's any way we could sort of bring structure like we had in our Rails applications. To these microservices and or other things. And, that got me thinking, like how can we get Rails in? And, it never sort of came about, or sort of I thought about it before. But, it was only maybe about a few months after the official Ruby runtime release.

It was kind of about that time I was like, how can I get Rails into this Lambda? How can I make it work? How can we put structures into these Lambdas? Not only for microservices but also for maybe full-stack applications, and is that even possible? And, that started about last year with the project that we had called Lamby. Which, literally allows you to drop a Rails application into Lambda.

Jeremy: Yeah, that's pretty cool. Tell me a little bit more about Lamby.

Ken: Well, technically speaking it is a small rack adapter. Your Rails application would, in most other environments, whether you spin it up through a thing called Passenger with Apache. You would just start a process and then you would send it messages. Rails has a, or at least Ruby has a system for talking to HDB applications called Rack. And, if you look at the data structure for sending messages to a Rack application, it's basically an event.

And, all Lamby does technically is; it converts either Application Load Balancer or API gateway events in to that Rack event. So, that your Rails application knows how to deal with it. Your Rails app is no wiser of whether it's mounted in Apache, or Nginx or anything like that. All it knows is it's just getting Rack messages.

Jeremy: Very cool. All right, so let's move on and talk about the architecture of the first project that your team did. This was a little bit interesting. You made some, everyone makes architectural choices. Every architecture looks a little different, but you used Application Load Balancer instead of API gateway.

Ken: Yeah. Right. So, we used our API gateway for a lot of our microservices, that had just come out at the point that we just made the Lamby gem. That ALBs became a choice. That actually felt like a comfortable choice for me. I had no other reason to use it other than I knew I didn't need the features of API gateway. The only thing we used it for was just basically proxying events right down to the Lambda. Even on our microservices. It was just all about that HTTP event. So, ALBs made a great choice for that. And, the architecture of our first Lamby app really sort of afforded us a new way to sort of adopt and look at the cloud. One key aspect that we really liked, was sort of infrastructure as code. None of our lift and shift EC2 instances other than, we're basically just configuration management.

Lambda through the AWS Sam framework afforded us this infrastructure as code first dip into these architectures. The app was eventually, it's kind of like a Photoshop in the cloud application as a rendering services. We talked to DynamoDB and that we even deployed this application multi-region for availability and redundancy. Use a latency based routing with CloudFront, and even tied together a DynamoDB and S3 tables. Through cross-region replication and global table usage. Even did some optimization of another Lambda that spun off on the side, where we did image optimization. So, traditionally a Rails application might approach background jobs through something like a Redis database. And, adopt a processing system called sidekick. And, one of the things that I've been really advocating for is; when you think about these full stack server-side Rails applications.

And, Lambda, you don't try to lift and shift your thinking of what you might do with container based development. Either with a sort of Fargate, our Kubernetes. You really look at all the constraints that Lambda gives you, and you look at those as opportunities and ways to sort of feature develop your application in that new method.

Jeremy: Yeah, and you have a great slide that outlines the architecture here. And, it shows, the latency based routing. It shows the DynamoDB global tables, and the replication in here and some of that. So, I will make sure I put this in the show notes because I think this is super interesting.

Again, I love seeing how companies or how developers are building big apps with it. Not these little point of, or at least a proof of concept type app. So, this is really, really interesting. So, once this was built right, and obviously it looks like it's a solid system. But, then you have to put it into production. So, how does your team measure success with this?

Ken: Well, given that I'm sort of a person that likes to think about application usage from a customer's perspective. And, the value that things deliver either for our customer or the business. For me success is adoption. That's, the bar right there. Do we get it out? Is it getting used by other platforms? Are our marketing and other sort of social teams picking up this application, and using it for onsite personalization? That success to me. Nothing in CloudWatch tells me if it's success or not. It's, if it's not performing, then we can optimize that. We can break apart the application into two smaller bits. Optimize the rendering engine. Move from ImageMagic to Libvips, et cetera. So, success always for me is; did it reach the customer? Did it provide business value for someone?

Jeremy: Yeah. And, I think that's important. Like did it provide business value? And, part of that was, I mean you mentioned the 90% savings. But, what about like time to market? Like how long did it take your team to do this? How many engineers did you use to do this?

Ken: Well, I will admit that I totally shaved a yak here. I had to make Lamby in order to get this app out. So, my performance on this one is probably not good. What I'm interested in is if other people can sort of take the work that I've done. And, the Lamby gem and the work that we've done, and sort of co-op that for them. And, I think that's a key part of what we're going to be doing internally at Custom Ink. And, the idea is simply this; if you can take this, create a new application or an optimization. And, simply do a Rails new or follow the Lamby docs and get that spun up in hours, to days. Then you've fulfilled like one of our most important tenants at Custom Ink. And, that is ownership.

Can you control everything from the application of the creative side, the frontend, the backend, all the way to production. And, own that process all the way through, whether it be to an internal team or an external customer focus tool. And, make it happen. And, I think with Lamby you can do that in hours.

Jeremy: Yeah. And that, you know what, and what I really love about what your team did with Lamby is the fact that you went out. You built this for your own purpose, but you're all, everyone's trying to solve their own problems. That's one of the big things we do. We try to have this, I guess philosophy in serverless where we're not trying to reinvent the wheel. But, sometimes the wheel doesn't exist yet. And, so companies like Custom Ink, will build these things. And, there's other companies too. Like Nordstrom has done all kinds of amazing, they have a bunch of tools and services that they've released. And, that's just really great to contribute back to the community, so that the next group makes it easier. Since we are very, very early still in tooling and all this other stuff that has to do with serverless. So, that's awesome. So, I get that it took you a little bit of time to sort of get Lamby up and running. But, once you had it up and running, you're saying is pretty fast process to build these applications.

Ken: Yeah, absolutely. The hardest part is building what you need for your customer. And, I think that's what the focus should always be on, and the time should be spent. Not about like how do you get this infrastructure? How do you spend up EC2 instances? How do you configure for gate or God bless it, Kubernetes?

That I think the time that you spend in your app is going to be the time that you're delivering the features. The getting it up and running and getting your first [inaudible 00:16:29] in the cloud, can be hours. And, there's a story that we're telling here. We have more work to do with Lamby to make that story better.

Jeremy: Sure.

Ken: So, for example, we just finished the adoption of our Aurora Serverless gem. And, that opens up moving from DynamoDB to sort of your traditional relational database with the Aurora Serverless option. And, the next step would be something like with RDS Proxy. And, then after that we would really like to have something done to where we have this integrated with the serverless application repository. Where, someone can literally hit a button and start off with a Rail 6 app. And, a full CI/CD pipeline. And, just go from there.

Jeremy: That's awesome. All right, so let's go on to the next sort of phase here. So, phase one, you built this application out. And, you've had some success with, you had a lot of success with it. You had to build Lamby for it. So, where's Custom Ink going now? What's the next phase?

Ken: Yeah, I think internally the story is a lot bigger than a Lamby. So, we're working on trying to figure out how to get a lot of our EC2 instances into things like Fargates, or some sort of container based system. After that, our Lambda story, which I'm trying to spearhead is really broad. That's going to be, we have a lot of data teams that are doing traditional sort of ETL style data management.

We want to move to real true event at architectures that are afforded to us with EventBridge and Lambda Destinations. And, popping events off either from Aurora or DynamoDB. And, those will more than likely involve a lot of sort of smaller either Node, Ruby or Python base, Lambda glue and or Microservices to do that. My hope is that over the next year or so we're going to have teams during our hackathons and other sort of business units spin up these Rails applications.

Much like the one that we did for our initial Lamby deploy. And, just crack open new possibilities. We've got a lot of stores launching. Like physical stores that you could walk into. The possibility for reinventing small parts of the company, are sort of numerous. And, the good thing that I try to position my thinking around, is; I kind of don't care what that innovation is. If, I can just make the tooling so that smart people on the edges of the company, can sort of take that tooling and just run with it. That's where I succeed.

Jeremy: Awesome. All right. So, what about some of these other things that you're building though? So, you had mentioned this idea of kind of bringing back RDS into the mix. And, with the last project you did you heavily adopted DynamoDB, you got the replication from it. The global table, some of that stuff. So, I'm curious, why the move or why the focus back to RDS or RDBMS I should say?

Ken: Yeah, I will admit that this is a purely sort of adoption. I want to give people the option to look at Rails, and its entirety in Lambda. And, that from traditional Rails is a relational database. All the tooling around Rails is built around an open source adapter pattern, which can facilitate anything from SQL server, Oracle, Maria, MySQL, Postgre, et cetera. So, I think it's really easy for Rails developer. A lot of the process in Rails for running database migrations, it's just built around these relational databases. So, first and foremost, DynamoDB is great. It does have a steep learning curve. I'm almost certain my first implementation of the single table strategy that I did is okay. But, I would have rather started with a relational database, and sort of migrated to there. And, that's the story that I want people to adopt Rails and Lambda with.

So, I knew that wasn't possible when things first came out. You, I believe the written sort of a Node package that sort of manages these zombie connections. And, I took the stance where I just didn't want to play with that. I just waited for about a year. And, I waited to see if something would happen. And, certainly I think late 2019 is when Aurora serverless came out. And, that opens up a connection to the database through HTTP. And, it took me about a couple months to get through it, but I successfully wrote an active record adapter gem. That monkey patches the MySQL connection, from native protocols to HDDP. And, it took me, let's see, over the Christmas break here, probably about a week and a half to do it. And, it passes all 6,000 active record tests.

Jeremy: Yeah, that's awesome. That's awesome.

Ken: That's, that's the first story in the database adoption. But, I think it's not complete. It's only really good for say, these infrequent workloads or applications that need to just kind of sit there. Maybe pet projects that people have on Heroku or good candidates. And, we've certainly, at Custom Ink, we've migrated our internal innovation app. Which, sort of allows people to share the ideas around hackathons that we run twice a year. And, we just pour that right on over, right off of Heroku and Postgres and migrated it to Rails with serverless.

Jeremy: Yeah. And, that open source package, you're talking about serverless-MySQL. I didn't want to build it either. It was just one of those things where it's like you had to at the time. And, the data API is great. And, that's the HTTP one that you're talking about. I've actually found it to be very useful for a number of things, especially in the fact that you don't have to put it into VPC. Which is incredibly helpful if you don't want to have to get sort of that extra latency in some of the, set up a Nat gateway. And, some of these other things you have to do if you're running a Lambda function inside of VPC. And then-

Ken: ...you had a performance cost with that as well. For the startup time.

Jeremy: Yeah. I mean that's kind of gone away. I mean it's still there. I mean, but it's nowhere near as bad as it was before. And, I think that you still have a problem with relational databases. You're still going to have some sort of scaling problems.

So, even if you handle the zombie connections, and you handle the connection pooling, and some of that other stuff. So, you're not overwhelming your database. You're still going to face scale issues I think when you get to a very active system. So, do you have any plans to sort of deal with that, or is that just something that you kind of, is up to the implementer?

Ken: Yeah, I do. I think right now I'm putting my effort into looking into the newly released RDS Proxy, in preview mode. And, I think that'll help out. I don't know, I haven't looked too deeply at it yet. I don't know if it's going to work or not. But, from what I've looked at, apparently you can use the same MySQL protocol. And, then which means it should be transparent to the Rails application. And, that it will manage all this for you. Even in some of our larger EC2 applications with Rails, we have issues with connection management. There's already a need today for the RDS Proxy.

So, bless their hearts if people do want to put Rails, and sort of bring this true Lambdalith into reality. And, use a relational database. I want that tool to be there. And, I want to tell a story with that. I actually think RDS Proxy can help out with that. Yeah,

Jeremy: Yeah. And, I think that, I've had this discussion with James Beswick. And, basically, RDS or relational databases aren't going away. And, there's a ton of, there's absolutely a need for them. So, they are very useful for the right types of applications. So, I do think that, that's, the RDS Proxy is an interesting way to try to solve that problem. Again, even if it solves the connection problem, there's still potentially getting a really big RDS cluster. Is going to have its limitations at some point too. So, it depends on what you're doing with it. But, certainly for most use cases, I think that, that makes a lot of sense. So, what is Custom Ink doing to sort of help other engineers in your organization learn serverless, and learn sort of this cloud native stuff?

Ken: Yeah, we've been working really hard over the past year to up our game at cloud adoption. And, that's a broad story. So, we've done everything from a lot of internal workshops either around Fargate, Kubernetes, Lambda and stuff. We definitely have, I think we just, we do A Cloud Guru teams account. We've started encouraging certification at all levels, everything from management to the engineers.

I believe we have maybe 20% of our team now certified. And, I come from certification as a weird topic. So, I'm certified for the developer associate, I'm working on my developer pro and I think the architect pro. And, coming from sort of an old schooling system to where I never got grades in my initial school, for some reason my parents sent me to some hippy school and I never knew what grades were. So, I tend to just do things for the doing. And, achieve where I want to achieve. And, I believe certification in some way is learning how to pass a test. The real skill comes from how you apply that knowledge. So, we've taken the approach that certification is a way to open people's eyeballs up. Just so that they can have a good candid architecture discussions, when we're doing designing and architecting without, not from an implementation point of view, but just sort of from an understanding. So, if you simply knew that S3 batch operations was a thing. And, that got you to implementing some sort of Lambdas, and inventive hooks and data processing. That's success. We don't look at certification as a way of saying, "yeah, I know how to implement everything from VPCs to Lambdalith to microservices and all in between. It's knowing about where to look first, and then going and finding it afterwards.

Jeremy: Yeah. No, I think that's a really good point. And, that's one of those things with cloud provider like AWS. There are just so many services and so many, so many sub-services in a way. Different features of a particular service, that just getting exposed to know that something like that exists I think is great. So, you're doing some training and you're doing some hackathons and things like that. Is it something that you give engineers extra time to sort of focus on that learning piece?

Ken: Yeah, absolutely. And, we do it in two ways. So, one of the other ways that we sort of encourage all the cloud adoption, is we formed an internal Guild. That we've simply just call the AWS ambassadors. And, basically we take some of our senior engineers, and we put them into this group. And, we look to sort of build out this cluster of people that have that sort of cross functional knowledge.

So, there would be an ambassador that focus mainly on machine learning, Sage maker, etc. I'm sort of the ambassador that focuses on Lambda, and these Rails applications. And, we have many more that fill those gaps. Of, all those AWS services. And, then I think with regard to the teams, we have bi-yearly hackathons. Every other Friday, people get to work on what they want to. Whether that be sort of learning or training. Or, they can continue the sort of, we call it the imaginate day.

So, traditionally when you hold these hackathons. For multiple days, you're going to sort of be working with different business units. People that are not really in your sort of small fire team or group. And, learning to solve sort of problems outside of your normal purview of project work and roadmap stuff. What happens is; is if you don't care and feed that process throughout the year. Then those things just sort of, they gain traction and then they kind of die off. And, the idea with the imaginate days is that you have time and are totally encouraged, whatever it is you're doing. Cloud adoption, solving a business problem, to pick that stuff up and keep driving it every week or so and just bring it home. So, it's really up. It's really the individual's gumption on if they go into the stuff or not. We've done enough on our side to open that door and one of them is the cloud adoption and training.

Jeremy: Yeah, I love that. I mean that's one of those things without, there's just so much to learn and there's so much that's different. That if you don't have sort of a constant stream, and have some time to read the blog posts. And, go through the docs and experiment with some things and do that. It becomes really a, I think you can fall behind very quickly. And, that can be very frustrating, especially considering that I think serverless gets more and more complicated every day. Because, they keep adding new things to do. And, while it's got a whole bunch of benefits. The learning piece of it is still pretty tough.

Ken: And, that was the huge reason why I wanted to approach it from Lamby. I know when you just said you and Chris Munns talked, you all joked a lot about the Lambdalith. And, I want people adopting the cloud. And, one of the things, I attended Serverlessconf 2019 in New York. And, it almost seems cliche that everybody is coming up with their own, I call them like these serverless specific micro frameworks. This is how we do it. This is how we're sort of using Lambda with full stack applications and stuff. And, I found it kind of tiring. Like if you can almost dedicate for each one of those, and it could be that maybe in two years or three years time. That is going to not be around anymore, or Lambda is going to evolve in such a way.

The, idea that we've gotten with sort of Rails into Lambda is that your Rails app can live on no matter what. I can move it from Heroku, I can move into Lambda. If, I want to I can move my Rails app from Lambda to Fargate or EC2 or DigitalOcean to wherever I want to take it. It will work. And, it's been, Rails has been working for many, many years. And, I like that idea that you almost have some sort of bulletproof portable, for those people that want to go, I want to be cloud agnostic, workload essentially. That can be put everywhere and it helps me focus on the innovation at the Lambda level. Like the provision concurrency. Which I don't think we need, but I can now start focusing on things like destinations and other things and how AWS works. Versus these micro frameworks and the tooling around them. But, then again, people are different. So, anyway, you get into the cloud I think is a good story.

Jeremy: So, I think that's really interesting. Because I mean one of those things or one thing to think about when building services for Lambda and other managed services. Is that we want to kind of forget about how we used to build applications in the past. Because, things are so different. So, Taylor Otwell built his Vapor project that allows you to basically take a Laravel project and stick it into Lambda. And use, SQS and the database and some of those other things to just sort of make a Lambda, sorry to make a Laravel project work. And, you've sort of done the same thing with Rails. Yours is open source a little bit different. But, how restrictive might that be? When we think about building applications, don't we want to build them? When we build serverless applications, we want to build them using very specific technology. Making very specific technology choices, component choices, things like that. Do you have any worries that Lamby will kind of box people in and maybe not be able to take advantage of all the best practices?

Ken: Yeah, I don't think so. I think, if your app is the app. And, you need to move that up elsewhere, that's going to be portable. What's not portable is the implementation that you put around CICD, the IM permissions, the other things like that. That's always going to be the cloud locket, and I've never been anybody that's sort of like not do anything for vendor lock in. That to me is like a flood that you can easily just call out in a meeting, and then just stop things from moving.

Jeremy: Right.

Ken: So, Ruby code is Ruby code. It's going to run wherever you put it. So, if you have it run in a Lambda, doing popping events off of S3. Then your vendor lock in or your portability is just going to be what events you listened to. And, the Ruby's going to do what the Ruby does. And, that's true for Node or Python or any language. I always approach it from the language is portable. The application is portable. The way you integrate with the cloud, let's say if you're taking full advantage of API gateway and you're, proxying it right to DynamoDB and doing all those things. Those are definitely not portable.

Jeremy: Sure.

Ken: They're very valid. If you want to build a mobile application with amplify. And, they tell a really good compelling story. I would never say someone don't use amplify because you're going to get vendor locked in into the full suite of full stack services that AWS offers. Go all in, get customer value. That's the thing we should be doing.

Jeremy: All right. So, that brings up sort of this interesting topic too because Rails apps are typically Rails app. I, would see them as sort of their own little microservices. You can certainly build them out that way. So, how do you see serverless microservices? Because, I think people think of them differently. But, what's the organization of a serverless microservice look like to you?

Ken: I think that the ones that we've traditionally thought about are image processing. So, custom make, we allow people to personalize apparel. So, we have a flagship product of ours called The Design Lab. And, everything that we've pretty much used serverless for, and microservices. Are going to be some form of image serving an image optimization. So, for us it's really around taking an HDP event and giving a binary image back. And, that could be because I was a graphic artist, but I think it's going to be different for a lot of people. But, most of our microservices center around image manipulation and returning images back.

Jeremy: And, that's with multiple Lambda functions or are you building them mostly with these Lambdalith?

Ken: You actually could describe these as a Lambdalith. So, the one that does a lot of our proof generation. It has a, it does all this routing internally. It basically can do maybe up to 30 different types of routes, and 30 different types of images for any type of product and or design that you're putting on it. That is a Node, microservice that we call. Its package size is probably 35 maybe 40 megabytes compressed. So, it gets up to the size there. Because we're sort of bringing the layers in for our Libvips and things. So, it's very possible. Somebody might look at that, and even though it's just a small Node application that does one thing. Return product and images back with proofs on them. Somebody could say that, that's a Lambdalith.

Jeremy: That's interesting. Yeah. I just, and you're having success with it. And that's, and I mean the same thing. You know Michael Hart and Bustle, they use these Lambdaliths to do a lot of the processing. And it's, because there's less overhead in understanding how each individual function works. They have the same sort of scale behavior. So, it's not like you need to be able to scale up one particular piece. But, even how you're breaking it out. So, I think that's interesting. And, I think that the way people approach this, that's why I just love talking to people like you. Because, I love hearing all these, I love how people are actually implementing it. Because, we know what the best, practices are or supposedly are. But, those tend to break down when you put things into production. And, in terms of how people find more success and actually in implementing that.

All right, so before you go at one more question for you, because I think this is always super important. Especially for new companies or companies that are just starting to adopt serverless. What's your advice to other companies that are looking to get started with Lambda, or serverless, or just even maybe just starting migrating some things into the cloud?

Ken: Yeah, I think it's always to look at what your business is doing right now. And, where you need it to be sort of performing at first of right. So, always drives my success. I'm a very huge believer in DHH the sort of creator of Rails. That you do the majestic monolith first. You build an application out, and then you sort of look at where it needs to either be performing or broken apart. For Custom Ink. If, your story is anything like ours, it would basically be starting with the monolith. Looking to where sort of business units lie in that monolith and then breaking out into what we sort of call key domain services. So, we would extract the design lab from the monolith. We would extract the product catalog from the monolith, we would extract, a group order form and quoting systems and things like that from the monolith.

So, that to me is a really good way to sort of adopt the cloud. If you know you're going to be breaking up to this monolith into smaller parts. Some of them could be Lambdaliths, some of them could be say Fargate or EC2 instances, whatever. But, I think when you look at what's happening with your current application, let your success drive your architecture. And, I think Lambda is a good place for either moving apps, but it's also a really good place for, if you're in AWS. To question if that's an opportunity for you to look at doing data, and events and units of work in a different way.

Jeremy: So, step one is not just break up your entire app into a bunch of different microservices.

Ken: Oh yeah. My predecessor for Rails Atlanta did, I think it's a similar architecture. It was called a system called Jets. And, if I remember right, the architecture looks similar where in Rails. You have sort of this MVC controller and action pattern. So, you'd have a controller, a controller can have a number of sort of restful routes. And, the way that, that was thought about is; it's kind of like what we did in 2014. Every controller would be broken up and every action into its own Lambda. And, essentially you might have 30 or 40 Lambdas talking to each other. And, I can't even wrap. I think I'm a smart person, and I can't even wrap my head around how you'd managed the CICD pipeline. And, the maintainability of that.

Jeremy: It does get complicated. Well, anyways. All right. Listen, Ken, thank you so much for joining me and-

Ken: Thank you for having me.

Jeremy: Well thank you for sharing the story of Custom Ink and Lamby. And, what you're working on. So, if people want to find out more about you or get in touch with you, how do they do that?

Ken: Well, I've got a couple of places, so in Twitter you can follow us @CustomInkTech. Or, me personally, I'm metaskills. M-E-T-A-S-K-I-L-L-S on Twitter. We have a little product site that we made for Lamby and that's available at lamby.custommaketech.com and of course we blog a lot at Custom Ink. And, that is at technology.customink.com.

Jeremy: Awesome. All right, we will get all that into the show notes. Thanks again, Ken.

Ken: Thank you so much, Jeremy. I really appreciate it.

Episode source