5 classes realized whereas constructing platforms for Knowledge Scientists.
Image this. You’re a person contributor working at some firm that requires you to write down “code” to get your job achieved. I’m attempting to solid a large web right here, for instance, you might be a full-stack information scientist at Sew Repair creating fashions that plug again into the enterprise, or you might be a software program engineer at a startup writing product options, mainly anybody the place you need to develop some “software program” and thru your work, the enterprise in some way strikes ahead. Basically, it’s straightforward to get began and ship worth to the enterprise, since issues are comparatively easy. However persistently having the ability to ship worth and doing it over time is difficult. You may simply attain terminal velocity and find yourself spending all of your time protecting your prior efforts operating, or preventing their particulars to increase and do extra, versus shifting your online business ahead. So how do you forestall this? Sooner or later you could begin constructing out abstractions to scale back upkeep prices and enhance your growth velocity, that is, in spite of everything, what all the large tech corporations do internally. What these abstractions construct out is a platform, i.e. one thing you construct on prime of. Now, constructing good platforms isn’t that easy, particularly as companies develop and scale.
I used to be fortunate sufficient to spend the final six years specializing in “engineering for information science” and studying to construct nice platforms for the world class information science crew at Sew Repair. Throughout this time, I noticed a lot of platform successes and failures first hand. Now, there’s loads of materials obtainable on what forms of platforms have been constructed (see any large tech firm’s weblog) and the way to consider constructing a software program product (e.g. constructing a MVP), however only a few on how to start out a platform and construct one out. On this publish I’ll synthesize my main learnings about easy methods to construct platforms into 5 classes. My hope is that these 5 classes will come in useful for anybody attempting to construct a platform, particularly within the information/ML area.
After I joined the information platform crew again in 2016, Jeff Magnusson had simply written Engineers Shouldn’t write ETL. I used to be excited to construct out capabilities for Knowledge Scientists who have been working in a no hand off mannequin. On the time it was an avant-garde method to run an information science division (when you haven’t learn both publish it’s definitely worth the learn). At a excessive stage, the platform crew operated with out product managers and needed to provide you with platform capabilities to maneuver Knowledge Scientists ahead, who in flip moved the Sew Repair enterprise ahead. As tacky because it sounds, what Jeff Magnusson wrote ‘Engineers ought to see themselves as being “Tony Stark’s tailor”, constructing the armor that forestalls information scientists from falling into pitfalls that yield unscalable or unreliable options.’ is true, we actually did get to dream large with the tooling we constructed. Now, how did issues work out in apply? Nicely some folks’s concepts and efforts flopped onerous and others have been smashing successes, therefore the motivation for this publish.
Earlier than we go additional, a fast work on nomenclature. I’ll use the time period “platform” in a free metaphorical sense — it’s something you construct on prime of. So in case you are somebody who gives an internet service API, a library, a UI, and many others., that different folks use to assemble on prime of, then you might be constructing a platform. I’m additionally being liberal with the time period “API” to cowl all your UX in your platform until famous in any other case.
Right here I’ll current 5 classes. Whereas the teachings might be learn independently of each other, I extremely advocate studying them so as.
Lesson 1: Give attention to adoption, not completeness
Everybody needs to construct the proper platform for his or her stakeholders, with all of the bells and whistles hooked up. Whereas that is well-intentioned, they generally fall right into a lure — that of constructing an excessive amount of with no early adopters. For these aware of the phrases MVP & PMF, that is mainly what this lesson is about.
Let me put this into context. The Sew Repair Knowledge Platform crew operated with out product managers. So every platform crew had to determine what to construct and who to construct it for. A easy resolution right here might be “simply rent a PM”, however (1) technical ones are onerous to seek out (particularly again in 2016) and (2) it will go in opposition to how we wished to function. Lots of engineers needed to be taught the onerous means that they couldn’t simply construct one thing in isolation; going off for 1 / 4 after which going “tada”🎊 wasn’t going to ensure anybody would use what you have been constructing. In actual fact, that was a recipe to get you fired!
Why would possibly this occur? Nicely, when you have a imaginative and prescient for a platform that fulfills a big selection of use circumstances, it’s tempting to construct for all use circumstances from the very starting. That is an arduous course of, and takes a very long time earlier than you arrive at one thing usable. My metaphor to explain that is: if you wish to construct a home (which represents your platform), you typically begin with all of the foundations, after which construct upwards, including partitions, the ceiling, after which as soon as the outside is completed, the internals — the home isn’t livable or usable till every little thing is accomplished. In the event you construct a platform this manner, it’s very straightforward to go away for a very long time and never have something to indicate for it. Worse but, you waste plenty of effort constructing a home that nobody needs, e.g. with just one rest room, solely to find your finish customers want a rest room for every room.
So as an alternative, one ought to attempt to discover a method to construct up “vertically” for a single room at a time, in order that it’s liveable and somebody could make use of it earlier than your complete “home” is accomplished. Yep, go forward, attempt to image a home, the place solely the construction for one room exists, that room is purposeful — that’s the picture I’m going for. Whereas we would not construct a home like this in the true world, we will at all times construct software program like this, so bear with me. That stated, modular development is all the craze lately, so possibly I am onto one thing with this metaphor… By increase a room at a time, you’ll get quicker validation/have the time to pivot/appropriate as you fill out the remainder of the home. Now, this doesn’t clear up the issue of understanding what room to construct first and thus who to construct first for. Keep in mind there’s a human aspect to constructing a platform. Figuring out who and getting their dedication arguably could make or break your undertaking. Listed below are two patterns that I noticed work effectively:
- Undertake current person tooling
- Companion intently with a crew and a selected use case
Undertake current person tooling
The information scientists Sew Repair employed have been a succesful lot. If there was a spot in some space of the platform, you possibly can make certain that information scientists stuffed that void themselves and constructed one thing. As a crew figuring out its personal product roadmap, we have been on the hunt for capabilities to construct and lengthen. Inheriting homegrown tooling/frameworks/software program made plenty of sense. Why? Adoption was all however assured — the platform crew solely needed to polish and generalize. In the event that they constructed a shack that labored for them, then coming in and doing a transform gave you a really particular set of parameters to work with. One caveat with this method is that you could see a much bigger imaginative and prescient than what their resolution presently gives, e.g. extra capabilities, or supporting extra customers, else you’ll be doing a transform for little seemingly profit.
For instance, there was a homegrown software that one of many groups had provide you with for their very own explicit enterprise context. It was a configuration pushed method to standardize their crew’s mannequin coaching pipelines. That they had constructed it as a result of they wanted it to unravel some very particular ache factors they have been having. We didn’t companion in constructing it as a result of we weren’t in a spot to assist such an endeavor on the time (we have been even skeptical of it). Quick ahead a 12 months, and immediately extra information science groups hear about it and wish to begin utilizing it. Drawback is that it was very coupled to the context of the originating crew, who had little incentive to assist different groups utilizing it. Excellent drawback for a platform crew to step in and personal! Importantly, we might see a grander imaginative and prescient with it and the way it might serve extra use circumstances. See this publish for the end result and extensions we added.
I like this method particularly as a result of:
- You didn’t spend time iterating your self to find out what to construct for folks to undertake it1. Win.
- You bought another person to show its worth. Win.
- You may then have good purpose to inherit it and enhance it. Win.
Observe: inheriting can get political at occasions, particularly when the particular person constructing it doesn’t wish to give it up. If there are clear platform accountability boundaries in place this isn’t a tough capsule to swallow, but when it’s a shock to the creator then choices are to have them switch to platform, or just have a tough dialog… Basically, nonetheless, this must be a win-win for everybody concerned:
- a win for the crew that created the software as a result of they’re now unburdened by upkeep of it.
- a win for you as a result of you possibly can take over the software and take adoption and capabilities additional than it will in any other case would have gone.
- a win for the enterprise as a result of it’s not losing sources on speculative efforts.
Partnering very intently with a crew and a selected use case
I recall one dialog with a platform engineer. They have been balking at suggestions that they need to be capable of ship one thing sooner for folks to get their arms on it. “No, that’s not doable, that can take two months” (or one thing to that impact). I agreed, sure, it is a problem, but when you consider it lengthy sufficient, there typically are methods for any platform undertaking to be chunked in a means that may present incremental worth to carry a stakeholder alongside.
Exhibiting incremental worth is necessary; it helps maintain you aligned along with your stakeholders/customers that you simply’re concentrating on. It’s also a great way to de-risk tasks. When constructing platforms you’ve got technological danger to mitigate, i.e. proving that the “how” will really work, and adoption risok, i.e. will somebody really use what I’ve constructed. With our house-building metaphor, that is what I imply by determining easy methods to construct a liveable room with out finishing your complete home. You wish to carry your stakeholder alongside from structure diagrams, to exhibiting pattern supplies, to constructing one thing that minimally works for his or her use case.
Virtually talking, a method to body delivering incremental worth is to do time boxed prototyping and make go/no-go selections based mostly on the outcomes. It is much better to pay a small worth right here and be taught to kill a undertaking early, versus getting plenty of funding with out mitigating the important thing dangers to success. Do that by concentrating on a particular, slender use-case, then figuring out easy methods to broaden the enchantment by increasing the platform “horizontally” to assist wider use-cases. For instance, after we got down to construct out {our capability} to seize a machine studying mannequin and allow no work on a part of the information scientist to deploy the mannequin, we partnered very intently with a crew that was embarking on constructing out a brand new initiative. You possibly can consider them as a “design companion”. That they had a slender use case with which they wished to trace what fashions have been constructed after which selectively deploy their fashions in batch. This enabled us to focus narrowly on two elements: saving their fashions, and proudly owning a batch job operator that they might insert into their offline workflows for mannequin prediction. Constraining it to a crew which had a deadline gave us some clear constraints with which to ship incrementally. First the API to avoid wasting fashions, after which the job to orchestrate batch predictions. As a result of we had a imaginative and prescient to assist different groups with these capabilities, we knew to not over index on engineering in direction of this one crew. By working intently with them we ensured we bought adoption early, which helped present precious suggestions on our supposed APIs and batch prediction performance. In flip, they bought a companion that supported and heard their issues, and was aligned to make sure that they have been profitable.
As an astute reader, you could be considering this simply appears like agile undertaking administration utilized to constructing a platform. My reply is sure, you’re mainly proper, however many a platform engineer seemingly hasn’t had this type of framing or mentorship to see the connection, particularly in a world the place product managers would do such a factor for you.
Lesson 2: Your customers aren’t all equal
As engineers we love constructing for prospects. It’s very straightforward for us to wish to be sure that anybody can do something with the platforms that we offer. Why is that? Nicely I’m stereotyping right here, however we typically wish to be egalitarian and deal with each person that we’re constructing for equally by way of offering assist and performance.
That could be a mistake.
Two info:
- Customers you construct for will fall on a spectrum (a bell curve, if you’ll) of talents. There can be common customers, in addition to outlier customers. Outlier customers are your most subtle customers.
- Options you add to the platform don’t contribute equally to growth prices and upkeep.
In my expertise, the outlier customers need your platform to assist extra advanced capabilities/wants, as a result of they need you to assist their extra subtle needs. This basically means larger growth prices and upkeep prices so that you can implement such a characteristic. So you actually need to ask your self, ought to I:
(1) design for this characteristic in any respect?
(2) then really spend time constructing it and sustaining it?
Or (3), push again and inform that person they need to construct that themselves.
You could be considering that what I’m speaking about is just a case of over engineering. Whereas, sure, this does have that taste, over engineering has extra to do with what the answer is, versus really deciding whether or not it is best to assist some performance within the platform or not. Utilizing our constructing a home metaphor, do you have to construct in some subtle customized dwelling automation system as a result of somebody needs voice activated lights, or do you have to simply inform the person to determine easy methods to present that characteristic themselves?
Except you’re seeking to construct a very new platform and trying to find a buyer, or there are compelling enterprise causes to take action in any other case, you as a platform builder ought to be taught to say no (in a pleasant means in fact). In my expertise, most of the time, these options find yourself being associated to speculative efforts. I discovered it’s higher to attend it out and be sure that this effort proves to be precious first, earlier than figuring out if it must be supported. Keep in mind, these asks come from subtle finish customers, in order that they very seemingly can get by, by supporting it themselves. Observe, when you take this technique, then it may feed into the “adopting homegrown tooling” technique from lesson 1.
Lesson 3: Summary away the internals of your system
Over time, much less and fewer infrastructure/tooling is being constructed inside a company because the maturity of expertise suppliers in no matter area you’re in has grown. Invariably you, as a platform builder, will combine with some third occasion vendor, e.g. AWS, GCP, a MLOps vendor, and many others. It’s very tempting, particularly if the seller solves the precise drawback you wish to clear up, to straight up expose their API to customers you’re constructing the platform for because it’s a fast method to ship some worth.
Exposing APIs like this to an finish person is a superb recipe for:
- Vendor lock in.
- Painful migrations.
Why? You’ve gotten simply given up your capacity to regulate the API of your customers.
As a substitute, present your model2 of that API. This could take the type of a light-weight wrapper that encapsulates this vendor API. Now it’s straightforward to do that poorly, and couple your API with the underlying API, e.g. utilizing the identical verbiage, identical information buildings, and many others.
Your design aim must be to make sure your API doesn’t leak what you’re utilizing beneath. That means, you keep the power to alter the seller with out forcing customers emigrate, since you retain the levels of freedom you could do it with out requiring customers to alter their code. That is additionally a great way to simplify the expertise of utilizing a vendor API too, as you possibly can decrease your customers’ cognitive burden by making frequent selections on their behalf, e.g. how issues are named, structured, or saved.
For instance, we built-in an observability vendor into our programs at Sew Repair. Exposing their python consumer API immediately would imply that if we ever wished to alter/migrate away it will be tough to take action. As a substitute, we wrapped their API in our personal consumer library, being certain to make use of in-house nomenclature and API information buildings. That means we might simply facilitate swapping this vendor out if we wished to sooner or later.
Observe, this isn’t an unreasonable method to additionally take along with your sister platform groups both when you use their APIs. Some rhetorical questions to consider, do you wish to management your personal future? Or, be coupled to their objectives and system design?
Lesson 4: Dwell your customers’ life cycle
In the event you function with product managers then they need to ostensibly know and concentrate on your customers’ life cycle, to assist information you as you construct your platform. As we had no product managers at Sew Repair, we have been pressured to do that ourselves, therefore this lesson. Now, even when you do have product managers, my guess is that they are going to nonetheless respect you taking up a little bit of this burden.
The capabilities and experiences that you simply present on your finish customers end in downstream results over time. Whereas it may be straightforward to gloss over the intricacies of your customers’ workflows, particularly in the event that they stretch previous your platform, doing so will inevitably end in tenant and neighborhood points (to make use of our housing metaphor).
Tenant points are typically small issues, like when simultaneous faucet utilization reduces everybody’s water strain. These issues solely require some small tweaks to repair/mitigate. E.g. you made it tremendous straightforward to launch parameterized jobs and other people clog up your cluster with work along with your cloud bills leaping up. What’s the short repair right here? Maybe you guarantee jobs are at all times tagged with a person and SLA, so you possibly can shortly determine who’s using all of your cloud sources/use it to make selections as to the place to route duties based mostly on precedence. Or, simply determine who you could discuss to, to kill their jobs.
“Neighborhood points” are larger issues. For instance, say you’ve constructed an superior home (platform) that may assist many tenants (customers), however road parking round it’s minimal; you didn’t account for this. Anytime somebody (i.e. a possible person) needs to go to the home they wrestle to park their automotive and need to stroll a good distance. If not fastened shortly, these points can actually harm your platform. To attempt to illustrate this level, say you targeted on making one facet of a person’s workflow very easy along with your platform, however you uncared for the way it matches into their larger image. For instance, you might need simply elevated the entire quantity of labor somebody wants to satisfy to get one thing to manufacturing, as a result of their growth work isn’t immediately translatable to your manufacturing platform system. By which case, your platform resolution that was initially met with enthusiasm, turns into dread as a result of there’s a explicit sticking level that your finish customers hit repeatedly. A smoking gun indicating that that is occurring is when finish customers provide you with their very own tooling to get round this drawback.
So what do you have to do? Stroll within the footwear of the top person, and take a macro view of how what you might be offering matches into what work they should get achieved. Listed below are a couple of approaches to mitigate issues:
- Be an finish person: really use your platform and get issues to manufacturing on it.
- Mannequin the hypothetical: draw the circulate chart of your customers’ workflows after which take into consideration ramifications of no matter platform characteristic you’re offering (works for each state of affairs).
- Usher in an finish person: carry a person on for an inner rotation — they need to be capable of perceive and clarify this to you and your crew (carry somebody to assist be a greater voice on your customers).
- Construct relationships: construct deep sufficient belief and relationships along with your friends such you could ask blunt questions like “what do you hate about your workflow?”, “if there was one thing you wouldn’t need to do in getting X to manufacturing, what might or not it’s?”. Generally your customers are simply anchored and resigned to the actual fact they will’t change the world, the place in truth they will by supplying you with suggestions. Different occasions they don’t really feel secure sufficient to provide the suggestions you actually need, so that you’ll have to construct belief for that to occur.
In the event you do the above for lengthy sufficient, you can begin to intuit what’s going to occur extra simply and thus decide what additional options you would possibly want, or potential points to anticipate and plan for.
Lesson 5: The 2 layer API trick
On this lesson, I put ahead my excessive stage framing of how I feel after I got down to construct a platform. That is basically the playbook I got here up with to assist ship profitable platforms at Sew Repair. I concede it won’t be at all times doable to satisfy this method as a consequence of tight necessities/the character of your platform. However as you construct larger stage abstractions it is best to be capable of apply this mind-set. In any other case as you undergo this lesson, you’ll hopefully see connections with the prior 4 classes. However first, some motivation.
Motivation
(1) bear in mind the delicate person of your platform that asks for that advanced characteristic? Because you stated “no, go construct it your self”, they are going to seemingly go forward and achieve this. However, in the event that they’re profitable you’re going to wish to inherit their code, proper? Wouldn’t you wish to make {that a} easier course of to inherit when you might?
(2) it’s straightforward to write down very coupled, non-generalizable code when offering platform capabilities, i.e. it’s onerous to interrupt aside and lengthen/reuse. This isn’t a nasty factor when you’re getting began and have to get one thing on the market, however it turns into an issue once you wish to lengthen your platform. In my expertise, particularly when you don’t have the time for “tech debt” tasks, it’s straightforward for such coupled code to snowball and thus considerably influence your crew’s supply of labor.
(3) in lesson three, the main target is on not leaking vendor API particulars. I feel that’s an excellent method, in impact you create two layers of APIs, however it’s fairly targeted on the micro drawback of vendor API encapsulation. How can we lengthen that considering additional and supply ourselves with some framing for our complete platform?
Two layers of APIs
To assist with sustaining and rising a platform, it is best to take into consideration constructing two layers of APIs:
- A backside layer permits one to construct “something” however in a bounded means.
- A second, higher-level layer gives a much less cognitively taxing, opinionated method to do one thing.
Utilizing our home constructing analogy right here, the lower-layer represents the home’s basis, plumbing and electrical; it bounds the form and floor space of the home. The upper-level API corresponds to what a room is; its options and format, e.g. on your customers you’ve got positioned the fridge, range, and sink to kind a kitchen triangle as a result of for anybody doing cooking that’s a fairly good setup. Then if somebody needs one thing extra advanced of their room, we’ve made it straightforward to take the partitions off and get entry to the plumbing and electrical to allow them to rearrange it how they need as an alternative.
Let’s increase on these two layers extra concretely.
What is that this backside API layer?
The aim of this “low stage API” is you could categorical something you need your platform to do, i.e. this API captures base stage primitives. That’s, that is your base functionality layer, utilizing it means you possibly can management all of the trivia.
The aim of this layer is to not expose it to your finish customers per se. As a substitute, the aim is to make you outline your self a transparent basis (pun supposed with our home constructing metaphor), with which to construct off of. Due to this fact it is best to contemplate your self the first goal of this layer. For instance, this layer might have APIs for studying and writing information in numerous codecs, the place to make use of it one must make selections about file names, areas, which perform to make use of for what format, and many others.
What is that this second API layer?
The aim of this “larger stage API” is to supply a easy expertise on your common person constructed solely on prime of your decrease stage API. You might be basically defining a conference into this API to simplify the person’s platform expertise, as you’ve got made some decrease stage API selections for them. For instance, constructing off the instance for the decrease stage layer, this layer might expose easy APIs for saving machine studying mannequin objects. It is a easier API since you’ve already made selections on file identify conventions, location, format, and many others. to avoid wasting that mannequin so your platform finish person doesn’t need to.
The aim of this layer is to be the principle API interface on your platform finish customers. Ideally they will get every little thing they want achieved with it. But when they should do one thing extra advanced, and it doesn’t exist on this larger stage API, they will drop right down to the decrease stage API you’ve got supplied to construct what they want for themselves.
Why two layers ought to work
By forcing your self to consider two layers you:
- Make it more durable for you and your crew to couple issues collectively. Since, by design, you’re forcing your self to find out how a extra opinionated functionality (larger stage API) in your platform is decomposed into base stage primitives (decrease stage API).
- You may extra simply certain how the platform takes form since you outline your base basis layer. This helps present assist for the extra subtle person you assist, who can peel again the opinionated layer and do extra advanced issues, with out you having to explicitly assist that. By enabling extra advanced customers on this means, you’ve got time to suppose whether or not it is best to assist their extra advanced use case in a firstclass method (see how this could feed within the “Undertake current person tooling” a part of Lesson 1).
Now a few of you would possibly react and balk on the thought of supporting two APIs, because it appears like an entire bunch of labor on API growth, upkeep, and versioning. To that I say, sure, however you’re largely going to be paying it anyway when you’re following good documentation and API versioning practices. Whether or not it’s inner or exterior to your crew shouldn’t actually change a lot, besides how and the place you talk. In the event you take the choice method of constructing a single API layer, your preliminary prices could be decrease, however the future upkeep and growth prices are going to be a lot larger; it is best to anticipate that your platform wants to alter over time. E.g. safety associated updates, main library variations, new options, and many others. My argument right here is that it’ll be simpler to take action with two API layers than a single API layer.
Two temporary examples
To assist crystalize this, let’s take a look at two examples of this two layer API considering in motion.
Instance 1
For instance, after we launched our configuration based mostly method to coaching fashions, it was constructed on prime of our mannequin envelope method to capturing fashions after which enabling deployment. So if somebody didn’t wish to use our configuration method to making a mannequin, they might nonetheless make use of the mannequin envelope advantages by dropping down to make use of that API.
Instance 2
At Sew Repair we made it straightforward to construct FastAPI internet providers, however customers didn’t really need to know or care that they have been utilizing FastAPI. That’s as a result of they have been utilizing a better stage opinionated API that enabled them to only concentrate on writing python capabilities, which might then be become internet service endpoints operating on an internet server; they didn’t have to configure the FastAPI internet service by writing that code themselves as a result of it was already taken care of for them. This performance was constructed on prime of FastAPI as the bottom foundational layer. Ought to a person need extra performance than the higher opinionated layer might present, one was in a position to invoke the decrease stage FastAPI API immediately as an alternative.
Thanks for studying! In case you’ve been skimming, right here’s what I would like you to take dwelling. To construct platforms:
- Construct for a selected vertical/use case first and ship incremental worth, the place both you inherit one thing that works, or goal a selected crew that can undertake your work as quickly because it’s prepared.
- Don’t construct for each person equally. Let subtle customers fend for themselves till it’s confirmed that it is best to make investments your time for them.
- Don’t leak underlying vendor/implementation particulars when you can. Present your personal skinny wrapper round underlying APIs to make sure you have extra choices you possibly can management when you need to make platform modifications.
- Dwell your customers’ lifecycles. Keep in mind that you present for and form the expertise of customers utilizing your platform, so don’t neglect the macro context and the implications of your UX; drink your personal champagne/eat your personal pet food as a way to guarantee you possibly can foresee/perceive resonating impacts of what you present.
- Take into consideration offering two layers of APIs to maintain your platform growth nimble:
(i) Take into consideration a bounded foundational API layer. That’s, what are the bottom stage primitives/capabilities you need your platform to supply, and thus what’s an excellent base to construct on prime of for your self.
(ii) Take into consideration an opinionated larger stage API layer. This layer must be a lot easier to make use of for the typical person than your decrease foundational API layer. To deal with extra advanced circumstances, it ought to nonetheless be doable for extra superior customers to drop right down to your bounded decrease stage foundational API.
In the event you disagree, have questions or feedback, I’d love to listen to them beneath.
I’m thrilled to share the insights I’ve garnered from my time at Sew Repair with you (hopefully they’ve been helpful!). Since I left, nonetheless, I’ve not simply been modifying this weblog publish. I’ve been scheming about constructing a platform myself. Keep tuned!
Additionally, particular due to Elijah, Chip, and Indy who gave precious suggestions on a couple of drafts of this publish; errors and omissions are all mine.
📣 Comply with me on:
⭐ Checkout GitHub — stitchfix/hamilton:
🤓 Learn some blogs:
📝 Join my upcoming mannequin deployment & inference class (TBD when precisely).
