Exploring All Things Serverless

Key Takeaways

hates Alex Williams the new stack here for coop accomplice cloud native Colin in Barcelona and today we're going to be talking a lot about the whole cloud native architectures that were starting to see emerge city in particular the whole emergence of functions and how functions have become such a popular and buzzy terms so to speak so joining me are Maddie Buchi Keys senior software developer Torico hi Maddie hi and Greg altschool co-founder and CTO of automate network thanks for joining us hi thank you so I'd like to first just talk about the landscape out there and perhaps you guys could talk about what what your roles are inside your companies so Maddie you were saying to me before you're working with Oracle on the API gateway you tell us a little bit about that sure so I think every cloud provider out there may be serious cloud provider out there provides an API gateway solution just to allow customers to to take away the worry of doing things like way limiting or tearing for the application so we're trying to do this in a more standardized way and make it more easier for customers to use hosted services like FN or object storage or any other any other service that we provide okay so FN and so that leaves my question for you and automate and automate is a company that you started Greg correct tell us a little bit about it sure so automate is a decentralized function as a service platform where developers can deploy their functions and when they're run it's since it's a centralized we go find a node wherever it is and it runs there and returns a result and you pay just for a compute time and smoke oil T if the if the developer wants to earn money functions that they run and all the functions are open so by default so you can't once you deploy it gets an endpoint and you can just call it anyone can call it can be shared pulled into new applications and ok so tell us a little bit about the Cerberus architectures that you are starting to see emerge and why you chose you know FN I know that you have a peer-to-peer network that you've developed and you built FN on top of that what were some of the reasons for that yeah so what we did was we took a technology took FN and we took another technology called lib p2p which is a popular peer-to-peer library and we sort of wrapped FN in that so that's kind of our communication protocol whereas FN is the functions as a service technology the reason what we did a lot of research on the different technologies that are out there we could have built something like this on lambda but then we would have been AWS lambda we would have been tied into that ecosystem or we could have chosen chosen any other kind of technology that is provided by a cloud like Google or whatever but then you're still stuck into those kind of technologies and there are other technologies like FN out there that kind of allow you to kind of build if you have your own data center you can kind of pull that stuff in and build like let's say if you have an enterprise data center you can build function as a service for your own organization but FN really gave us the flexibility that we were looking for to kind of make that wrap nicely with Lapita p so that we can kind of run these nodes wherever they might be it could be in an AWS or Oracle's cloud or it can be in someone's basement if they want to so kind of allows for that flexibility whereas the other technologies that we looked at didn't really provide as much flexibility as we needed there are platforms out there such as open fast for example that that offers that capability to work across different cloud services and we're starting to see more the usage of containers with with different service environments than to be able to make that portable there's also the promise of kubernetes right and Kay native so I'm curious in like what a maybe you both can comment about what are some of the advantages and disadvantages that you're starting to see in the market and you know why you may decide to go this way instead of like kubernetes can ADA which seems to be growing in popularity sure so we could have used kept kubernetes but it didn't really play too nicely with let's say deploying in on compute resources that aren't really known like if someone just wants to spin up a node and connect to our network kubernetes wasn't really the right technology for that so we don't actually use kubernetes we kind of we use our the lit p2p layer for discovering where nodes are and then we when someone calls a function we find a node that has available compute resources wherever it may be and then FN gets that request ultimately and a docker image is pulled in in by FN and run there does that make sense I think so if it's a what you're saying is like that p2p layer serves almost as that Orchestrator correct yeah so the orchestration is it's sort of our business logic that we wrote in the wrapping of Lapita P and F n so we took those two we kind of married them with our needs wrapped around that to kind of do the the actual archive orchestration in a it's we're at work sort of a block chain adjacent company so we use public and private key cryptography to kind of secure all this stuff and it just it out of the box with lid p2p that stuff so it didn't release lend itself to using kubernetes we could use kubernetes to deploy our technology let's say if automate wants to run a nodes in let's say a bluegrass or Oracle we can use kubernetes there to manage our own cluster of automate nodes but to automate Network it doesn't really kind of lend itself to the bigger peer-to-peer picture maddie when you're you're developing API gateway and before you're talking about functions and what what what is your team's philosophy up functions and how they play with the API gateway well in terms of building function as a service we are actually looking at using kubernetes and actually using the oracle kubernetes engine to try to build our own infrastructure so build out of the control plane or the data plane using kubernetes we've had a couple of pocs on that and it actually lends itself very well to to this functions infrastructure with api gateway we're still exploring but we with API gateway we started with with kubernetes and now we started because we wanted something more simple we built our own Java services for that but for effin I think actually kubernetes is a provides a very very good infrastructure Orchestrator to to manage our services so just tell me with that distinction again so for API gateway you're not using kubernetes did you say do you explain that to me we're not we're we're still exploring because we're still in like POC phase we tried using kubernetes we've we've stepped away from it just because of the mostly but because of the security concerns that we had with API gateway we have a control plane and a data plane and the data plane is accessible to the customers so if we have a breach from the control plane to the data plane then from the data plane you basically have access to all of the customer tendencies so you don't really want to have that kubernetes it is it very secure the community is doing a very great job of identifying security issues and and having patches for for those security issues but given that the the way kubernetes works the the cube API and the cubelet the way they communicate it might not always be secure in our in our specific case for API gateway this type of communication you know back and forth was not was not the best he didn't let in itself in the best way for functions I'm not working on the functions team but I know I do know that they're working with Oracle kubernetes engine to create their node pools and manage their their services they're out there looking at that to see whether this would be a good a good design approach it's an interesting topic to think you know when you're starting to research how you have to how you have to think of your security posture in cloud native environments and yesterday there was a discussion about zero trust and how the zero trust model is changing now with cloud native architectures due to you know the different types of capabilities for you know for an attacker to do for instance or a remote execution attack you know through a plug-in for instance so because they could then have that lateral movement you know across across the environment is that part of the is that part of that is that part of that kind of the posture you're trying to adopt is trying to you know thinking about these cloud native architectures and how you have to think about them differently from that security perspective yeah definitely where as I said we're trying to make sure that we're limiting the communication and the vulnerabilities as much as possible and I'm not sure whether kubernetes is more like a swiss knife so i think for it lends itself better for for applications for services not necessarily for a provider we are a provider servus we want to build the architecture we want to be in charge of the architecture so this is why we kind of have some a little bit of trust issues we are you know we are handling very sensitive information we have huge customers we we have governments as customers as well so we we are very very security aware so your so tell us about your security posture then and what what what what you're trying to achieve by using a fan and this peer-to-peer network underneath it sure so you mentioned zero trust and we are we're working towards a trust list protocol where the since we're peer-to-peer what's the trustless protocol a trusses protocol means I don't have to trust that basically when when I'm connected to one node everything is secure from my note to your node so there's no like there's no adjacent anything it's literally one computer to another once someone wants to run a function we find them an execution node that has compute resources and then there's just a direct communication between those two nodes and nothing leaves those two nodes so everything is secure from the moment it leaves my machine to yours if let's say I'm running a function on your node public and private key cryptography once it once it gets there that we were aiming towards a completely secure container environment which is what we're currently looking at is a docker image within a blanking on the name it's it's an IBM technology another container not container d it'll come to me I'll get back to it basically it's a secure container where you need keys to actually access the container and it's all locked in hardware so that whoever is running that node can't actually attack what's inside of it okay so that's interesting and so what is it that you know what is it you're trying to achieve by taking that approach as opposed you know to more I don't know it's just an is it a new set of what are some of the new set of factors that you're needing to need to consider when taking that approach right so so the reason why we're taking that approach is because we can achieve really cheap compute and so if we're if someone is incentivized to run nodes through a cryptocurrency they can earn that that cryptocurrency for running a node in exchange for running functions on that node so basically they're selling their compute so you have people who have data centers in their house they live somewhere where energy is really cheap and they can run notes they can run our no they can run other nodes like etherium or whatever it is side by side but they're basically running a data center and they're selling their compute and you can achieve much cheaper compute than if you let's say run in an AWS so we're looking at a blend of things depending on what our customers need so if they care a little bit less about where their functions are running they can choose nodes that are maybe less secure and that's up to them if they want to trust us as automate will be running nodes and we can we can assure them that they're running in AWS and everything's secure because we will we will be the provider of that secure environment how are you how are you seeing functions as a differentiator for an API Gateway for example in what sense could you clarify well you know API gateways are well known I mean you know as we were saying before Amazon has an API gateway and so Oracle's you know developing its own API gateway and I'm curious about the role of you know functions as a service within API gateways and what does that provide you a you know what does it provide you as a differentiator or how does that make it unique well I think because we are trying to to compete with all the other cloud providers it's something that we have to have had you know API gateway as a service and the fact that we want to we want we wanted to to promote both functions in API gateway because they are so simple to use and the I think at the end of the day when we talk about serverless we want to talk about simplicity for customers right we want to we want customers not to care about what's happening in the background not to care about you know how to configure an API and how to write an API gateway just how to configure it at a very very high level and with functions it's kind of the same principle right you don't want to know what's happening in the background what's happening with the actual infrastructure you just want things to happen without you having to have all that knowledge that there's a lot of knowledge that you have to have in order to build that infrastructure and maintain it and then in terms of your own so you know going back to your own security posture kind of in that respect what are some of the you know there what are some of the what are some of the features that you're building into an API Gateway to me because you know with functions and API gateways you know that attack services is extremely kind of wide what are you doing to kind of make sure that you you know that that API go way is secure well we have in terms of architecture we have a control plane and a data planes and in the data plane this is where we actually run the container the Gateway containers and the gateway continue we try to make the gateway containers as tight and secure as possible we are actually our container images I have very very limited libraries available over there we have selinux enabled and we are going above and beyond with selinux to enable all the features that would make it as secure as possible I see Linux isn't easy no it's not that's the thing and that was another reason why you know kubernetes does support selinux now I think it's only recently but it doesn't really have everything that we need there is a lot more to see than extent you know that is the box I guess right like what usually I know that phrase specifically with with kubernetes it would have been difficult to tag specific pods for this I I wasn't I wasn't involved and so I don't know specifically all that all the technical details about this okay no it's fine no it's fine no I think it's really interesting I think it's kind of a space that we're still trying to understand I mean you know in a it make it makes you think about about the overall software supply-chain out there - and there was that you know we there's well publicized docker you know hack that happened a few weeks ago and I guess I'm curious about you know not necessarily that but maybe no Greg how are you how do you then kind of develop your posture understanding there there are these is it there is this you know software supply chain out there and you know containers can be shared so easily and they're so portable and yeah and that's their value but it's also their risk and so I'm curious on your thoughts yes that's a great question we are a completely open platform so our docker images are we want people we want that portability everything's open the tokens we are we are very much on the on the side of open source everything our whole platform is open source we expect that people who write functions on our platform write functions and our open source and that their docker images are open and portable our compute resource can be moved around it's out there like anyone can run an automate cluster within their own cloud and pull in these docker images and completely not connect to the wider automate network they can do that and we want we want people to be able to do that we think that sharing resources like that and sharing functions and and ideas not just a static hoe but as running services is going to be the future and we want to try and help make that possible that said people can do things that are not the the greatest ideas like log keys right let's say a function developer has their own database and this function needs to read from that database and that database happened that connection happens over the internet we don't want people storing their keys to the database in the docker image but that's not really the system's responsibility that's the developers responsibility they have to understand the risks of developing an open platform if you commit code to an open source repo you also similarly don't share your keys and and things like that so as long as you're developing smartly on our platform hopefully the attack surface is from the system is non-existent because again we're trustless and hopefully people are developing smartly so that they not they're not exposing things how do you view that shared responsibility then at Oracle there's a shaming that's become a term we've heard more of like the shared responsibility you know it's it's not all the cloud services responsibility nor is it all the the you know the developer or the customers responsibility in terms of functions again I think we have kind of like the same approach we control playing the data playing yeah so in terms of architecture we do try to make it as secure as possible but when it comes to the containers we are trying to they it is a little bit of so that that's what I'm saying it is a little bit of the customers responsibility to be a little bit at least a little bit security aware we are trying to do everything possible in terms of architecture to make sure that even if you break out of a container you cannot you cannot attack any other customers so we do try to make that you know to make it to what to ensure that that happens but you know the customer is in charge of his own container there's there's only so much you can do education you need to educate the the user and the developers do you think it's a it's a fine balance to define you know line two to like two to keep on to keep in balance because as I said you know service is about simplicity it's about abstracting away as many concepts as possible from from the customer they're not supposed to know what's happening in the background but they yet they do have to have some basic concepts about I'm hearing more about this concept of minimalism almost kind of in these environments right you know you don't want to like bloat your container right you know for example there's things you can do such as you know you know hackers like to find containers have package managers in them example and you know and I was talking with a technologist from Google yesterday and she was saying that you know they're encouraging people not to use package managers in their containers so there's all the there it is a constant education isn't it yeah and to this point actually we what we use for to create our containers for both functions and a fan we are using an outsourced tool called Smith which is basically taking away all of the libraries that you don't need and it's only exposing the ones that you do need [Music] tight list of libraries that you're going to use so our container images are tiny and you know exactly what's in them we know exactly what services mm-hmm yes that yeah that's an interesting concept I think we'll be exploring more and also more like we're starting to see more a stronger security posture and open source projects overall open source projects are starting to just you know who's just starting to see it starting to talk you know but we actually bring more people who have security backgrounds into the projects themselves and I imagine that's kind of a posture that you guys are thinking about quite a bit especially if your honor you know you know kind of appear peer-to-peer network for example yeah I mean that the just to dive a little bit more into the trustless concept the concept is you don't have to trust us like if we're a cloud provider you know we're saying to the customer you can trust that our cloud is secure because we say it's secure we've done these things that make it secure the the trustless component which is is very prevalent and blockchain is trusted technology it's all open source you can read it it's public private key technology you can see for yourself that your data is being passed in a secure way so we're gonna keep kind of beating down that path to make sure that not only are we saying that it's secure because we say it's secure but you can look at the technology at the software at the code and determine for yourself whether you it's secure enough for your application so it's spring of 2019 2020 I'll be here she'll probably feel like it's gonna be here tomorrow right so what are some of the top priorities for example that Mady date that your team is looking at over the next six months when you're thinking about you know the API gateway and the integration of functions into it I think for us and my personal opinion is that if we want to make server less successful in mature we want to we want to convince bigger customers to to try to use serverless in their own infrastructure we've seen a lot of startups using functions and API gateways and things like that it's very easy to like everyone does the demo when they upload an image to the cloud some of them some data processing is happening and I'm and you know this is my app what we're trying to I think and this is going to mature the technology a lot more as to to into so we're going to what we're trying to do is to integrate as much as possible with OCS services such that you can use things like auditing and lauding logging and metering to to have like something like a self-healing infrastructure for example on on OCI so you don't have to have to have a system admin to take care of your infrastructure you can have a look at you can you can have triggers to see you know if I if my instance is that I don't know 80% of CPU utilization spin up a new one with functions you know by integrating this with functions you can do that and showing I think showcasing more of these use cases is going to take the industry a little bit further and it's gonna make this make this technology kind of greedy stick hmm how about you right so for us we're very early we're startup yeah I mean I I went to the site and I put my email in so I'm waiting for the launch it's pretty bare-bones right now so our our goal right now is to make sure that we have a delightful developer experience for our server list technology our our install is under ten minutes you can get a function running in in less than 30 so we want to keep us in 30 minutes yeah so we want to make sure that every single piece of our technology is delightful to use as as that so we need to add logging we need to we need to integrate with various data sources local test frameworks that that allow you to test your functions before you deploy and then also building up the set of function since we're we're an open platform we want as many kind of useful functions out there as possible so getting these github repos that are kind of popular instead of pulling it into your own codebase and deploying it into your own cloud why don't you run it on automate so getting getting some of these the stockpile of functions built within different market verticals that's what we're focused on so what about Kubik on what do you guys what are some of your interests here what are you where are some of the sessions you want to go to where some of the conversations you've had already that you're that are making you curious and wanting to learn more about something Maddy well I have a couple of talks I have a couple of lightning talks to do and I'm at the Oracle booth so I'm gonna have try to have as much time as possible you know it's of explorer to explore the the actual conference I think I really want to learn more about sto and like the newer components as I said we are trying to like bring as many of the of the other cube principles into our own infrastructure because I think that they are you know they're they're are really mature and it's good to bring that bring that back into your your architecture and try to see if that works if that actually makes makes a better product if that improves availability of improved security or things like that so yeah I'm trying to look from that perspective like what can i what can I steal to bring into my own architecture yeah for me I'm just gonna I'm doing a few lightning talks I throw Cooper's booth as well I'm really interested you can kind of see what the landscape is see what kind of new things are popping up to see what we can kind of pull into art our technology I'm also looking to socialize automate and see what people think you know just get and get get the idea in front of people who would actually be our customer Wednesday API gateway gonna be available we don't know for sure yeah well thank you both for taking the time to talk today really enjoy the conversation the security story is I think of real interesting so keep us posted on your developments and we look forward to talking soon thanks Maddy thanks great thank you very much thank you