altsang

for sure, it's like the Golden Gate bridge too - once you're done on one end of painting it's time to start re-painting from the beginning again

LoopBack.io powers the Compose capabilities in LunchBadger. We're built entirely on open source! Super productive for API development - we just fill in the rest of the blanks in the lifecycle

it gets better over time :)

Not exactly in the traditional sense, a Dapps is a decentralized app that runs on Ethereum, to bridge the gap beyond blockchain execution, the embodiment of a Dapp across all of its smart contracts to a traditional application is ideally - a microservice (and API) :)

thx! been a fantastic and learning experience, we've found a sweet spot for blockchain backed APIs and orchestrated microservices with our offering and it's been very exciting!!!

There are no hard rules about how to divide up your microservices and how atomic each one can be. This is an example at the lowest level as projected by Nginx.

We recommend deploying microservices that are encapsulated by domain because 1. locality of operations, 2. dependencies are going to require you rev as a unit. For us, that model could be running in it's own container or with several other related models.

We're talking to many new gen cloud companies that are already in production and have a burgeoning business that they have to support. They're all "sensitive" to cloud lock in and portability is definitely of concerns. What's also interesting is that many have moved from cloud to cloud like AWS to Azure. And many have a combination of clouds as well - a lot more than an I had anticipated!

Everyone who's been in the trenches know that scorched earth big bang replatforming rarely succeeds and never gets completed. Use scripting to wrap around your existing services, carve out microservices with clean interfaces, intense domain focus and go distributed the way you had hoped. We help you do this 0-60 flat in visual canvas, full source code transparency, saving you tons of time repeatedly.

We've standardized on docker containers, so any scheduler should be able to run your APIs and microservices. For now we've used Kubernetes for deployment and managing those containers. If you have your own scheduler it would be possible to swap it out with an on-premise deployment. What Kubernetes lacks in terms of dedicated professional support it makes up with the most active and helpful community.

Thanks! We think what we've built can potentially give you the best of both worlds. No one is going pigeonhole your entire API solution into just serverless infrastructure. But a portion of it can be and should be if you want the most efficient cost of compute and manageability.

Very very true. Cost of compute is already published per cloud provider. For example, on AWS, it's currently first 1M is free. After that it's a million per $.20. At some point of volume depending on your use case there's going to be an inflection of just running your own container or VM. The bigger challenge here is tracking and understanding your usage as it pertains to your application, beyond the compute resources on a per call basis. We're intending on building governance and metering for infrastructure usage as part of our orchestration solution to help shed light on this area.

That's true to a certain degree. Bare metal VMs running containers server give you OS ioslation but at a cost of an abstraction layer that is not necessarily needed if your interest is only at the container level. That's pretty much why CoreOS, RancherOS and other technologies are out there to be as slim of an OS to just run containers and the bare minimum system processes required. Even system processes are run as containers in RancherOS! APM and other system monitoring tools need to be tweaked for a huge multiplier of processes that are now your distributed app versus that one process that might've been your JVM for example. There's a concerted ops and devops effort that's required to hook into your orchestration layer to get that kind of insight. Roman's next post is going to cover the reasons why we chose the OSS orchestrator that we did.

When it comes to APIs and microservices, you're almost inevitably faced with container sprawl - especially with the ability to deploy quickly and deploy often. Having a good orchestration as described in this post gives you the ability to mind those containers across multiple machines - bare metal or VM, doesn't matter.

We run on top of AWS Lambda - if you choose. Lambda is great but there's still a TON of scaffolding and boilerplate to get your APIs up and running including: model mappings, routing, point to point connection to either HTTP based proxies or Lambda functions. We simplify all of that utilizing the Serverless Framework running LoopBackJS models.

If you're not on Lambda or don't want it - the model logic can be run within our optimized container based runtime built on Kubernetes. Everything is transparent either way built on open source. Where you run it is your choice.

if you're on a AWS, we utilize Lambda to get cost efficiency and predictable cost of execution, we also have a container based runtime that can run your APIs along with everything else that's part of the LunchBadger infrastructure to be run wholly on-premise in your private cloud. To the developer - they write a JavaScript/Node function realizing the serverless simplicity in building out their APIs.