{"id":685,"date":"2019-05-21T10:16:52","date_gmt":"2019-05-21T08:16:52","guid":{"rendered":"http:\/\/blog.zhaw.ch\/splab\/?p=685"},"modified":"2019-05-21T12:47:39","modified_gmt":"2019-05-21T10:47:39","slug":"evaluation-of-aws-private-cloud-options","status":"publish","type":"post","link":"https:\/\/blog.zhaw.ch\/splab\/2019\/05\/21\/evaluation-of-aws-private-cloud-options\/","title":{"rendered":"Evaluation of AWS &#8220;Private Cloud&#8221; options for serverless computing"},"content":{"rendered":"\n<p>While hybrid, multi- and <a href=\"https:\/\/blogs.cs.st-andrews.ac.uk\/crosscloud19\/\">cross-cloud<\/a> applications are on the rise, even for scenarios in which purely public cloud deployments are planned, having an equivalent private cloud stack available is useful in many ways. With the relative portability of popular open source cloud stacks, this is rather trivial to accomplish. For many large cloud providers, there are commercial solutions like Microsoft&#8217;s <a href=\"https:\/\/azure.microsoft.com\/en-us\/overview\/azure-stack\/\">Azure Stack<\/a>, IBM&#8217;s <a href=\"https:\/\/www.ibm.com\/cloud\/private\">Cloud Private<\/a>, Oracle&#8217;s <a href=\"https:\/\/blogs.oracle.com\/cloudnative\/announcing-oracle-cloud-native-framework-at-kubecon-north-america-2018\">Cloud Native Framework<\/a>, Google&#8217;s <a href=\"https:\/\/cloud.google.com\/anthos\/\">Anthos<\/a> (n\u00e9e CSP), Alibaba&#8217;s <a href=\"https:\/\/www.alibabacloud.com\/product\/apsara-stack\">Apsara Stack<\/a> and Amazon&#8217;s <a href=\"https:\/\/aws.amazon.com\/de\/outposts\/\">AWS Outposts<\/a> (as well as Greengrass for Lambda and other specialised offers). Yet sometimes, these are not an option for technical or business reasons. In this blog post, alternative options are discussed.<\/p>\n\n\n\n<!--more-->\n\n\n\n<p>To run Lambdas and other cloud application logic on private installations, both the Function-as-a-Service (FaaS) and the Backend-as-a-Service (BaaS) side need to be properly established. The FaaS side includes the Lambda runtimes and the deployment of resources according to the Serverless Application Model. The BaaS side includes databases, message queues, API gateways and other <a href=\"https:\/\/blog.zhaw.ch\/splab\/2019\/05\/13\/insights-into-aws-sar\/\">popular Lambda-connected backends<\/a>.<\/p>\n\n\n\n<p>One of the first open source equivalents of the AWS cloud services has been <a href=\"https:\/\/www.eucalyptus.cloud\/\">Eucalyptus<\/a>. It is still a viable option for the &#8220;mammoth&#8221; services on the infrastructure level (EC2 virtual machines, S3\/EBS storage, CloudWatch monitoring) but especially on the serverless side is by itself not sufficient. Lambda-API-compatible function runtimes such as <a href=\"https:\/\/github.com\/serviceprototypinglab\/snafu\">Snafu<\/a> could fill this gap, but again, cloud development has been fast and crucial features such as SAM support would be lacking.<\/p>\n\n\n\n<p>Instead, another combination appears to be more appropriate: The combination of<a href=\"https:\/\/aws.amazon.com\/de\/about-aws\/whats-new\/2017\/08\/introducing-aws-sam-local-a-cli-tool-to-test-aws-lambda-functions-locally\/\"> SAM Local<\/a> (based on <a href=\"https:\/\/github.com\/lambci\/docker-lambda\">docker-lambda<\/a>), <a href=\"https:\/\/localstack.cloud\/\">Localstack<\/a> and some glue code. SAM Local runs Lambda functions locally in a Docker container and simulates event triggers. Localstack implements mock services across the AWS portfolio. The glue code is necessary to ensure that all tools and outbound network operations are redirected to the local deployment. There are two main strategies for the redirection: code-based and infrastructure-based. In the following, they will be explained for simplified interactive (test) sessions, with slightly different parameters when using them for permanent (production) cases.<\/p>\n\n\n\n<p><strong>Code-based redirections.<\/strong> These work on a programming language or library level and require endpoint modifications to the invocation of tools or functions. A general advantage of code modifications is the portability of the results irrespective of specially crafted infrastructure and networking setups. Modifying any library in particularly has the additional advantage of enforcing endpoints across applications without requiring many code changes, but this may not always be possible, requiring the modification of invocation instances instead. For example, using the AWS CLI in shell scripts would be rewritten as follows, assuming a Lambda-compatible <a href=\"https:\/\/arxiv.org\/abs\/1701.05945\">control plane API<\/a> runs at port 10000:<\/p>\n\n\n\n<pre class=\"wp-block-preformatted\">aws --endpoint-url http:\/\/localhost:10000 lambda list-functions<\/pre>\n\n\n\n<p>For Python and JavaScript (Node.js) code, the two dominant programming languages for Lambdas, the respective binding libraries (AWS SDKs) provides a similar override, and likewise for other programming languages. In Boto, the Python library, the endpoint is specified as follows:<\/p>\n\n\n\n<pre class=\"wp-block-preformatted\">import boto3<br>my_client = boto3.client('SERVICE', endpoint_url='http:\/\/localhost:10000')<\/pre>\n\n\n\n<p>Precise patching would require loading any code files into an abstract syntax tree or JSON tree representation and roundtripping back into code after transforming the tree, e.g. using <a href=\"https:\/\/www.mattzeunert.com\/2013\/12\/30\/parsing-and-modifying-Javascript-code-with-esprima-and-escodegen.html\">esprima\/escodegen<\/a>. A more pragmatic approach would be the use of regular expressions for &#8216;monkey-patching&#8217; any relevant code parts. To give an example, the following slightly heuristic sed expressions perform a non-destructive endpoint URL addition on Python code as shown above:<\/p>\n\n\n\n<pre class=\"wp-block-preformatted\">s\/,?\\s?endpoint_url\\s?=\\s?('|\\\")[^'\\\"]*('|\\\")\/\/g<br>s\/(boto3_client([^)]*)\/\\1, endpoint_url='http:\/\/localhost:10000'\/g<\/pre>\n\n\n\n<p>And the following expression does the same for Node.js code:<\/p>\n\n\n\n<pre class=\"wp-block-preformatted\">s\/(new AWS.[^(]*({)\/\\1endpoint: \"http:\\\/\\\/localhost:10000\",\/g<\/pre>\n\n\n\n<p>On the SDK level, the modifications are slightly easier. For Python, for instance, the Botocore library provides a DEFAULT_ENDPOINT defined as &#8220;{service}.{region}.amazonaws.com&#8221; which can be redefined as needed on the code level (in the botocore file client.py) or through dynamic programming.<\/p>\n\n\n\n<p>A subtype of code-based redirections are those involving a proxy server to whose endpoint (e.g. on localhost) is used in the code. Again, portability and unprivileged operations are the advantages. Many proxy server designs would be possible, similar to e.g. <a href=\"http:\/\/morebalance.coolprojects.org\/\">morebalance<\/a> on protocol-agnostic content, and based on <a href=\"http:\/\/www.mattbeckman.com\/2009\/09\/18\/using-the-acl-in-haproxy-for-load-balancing-named-virtual-hosts\/\">haproxy<\/a> for HTTP. A dedicated proxy server such as <a href=\"https:\/\/github.com\/mhmoudgmal\/localstack-single-endpoint\">localstack-single-endpoint<\/a> acts as endpoint concentrator and multiplexes requests based on AWS-specific header content. A disadvantage of all proxy concepts is the loss of scalability, as all requests now need to traverse through the proxy, and the need to operate one more piece of software as part of the stack.<\/p>\n\n\n\n<p><strong>Infrastructure-based redirections.<\/strong> These require modifications to the name servers using DNS redirections, and are therefore disadvantaged by requiring administrative privileges which may not always be available. There are two subtypes, isolated and globally connected setups. In isolated setups, a local DNS server redirects all requests to a specified host, whereas in globally connected setups, only specific domains (e.g. *.amazonaws.com) are redirected and the others are passed through to an authoritative nameserver. This may be necessary, for instance, if a Lambda function retrieves information from an arbitrary Internet host or external web service. In both cases, the local cloud hosts require the new DNS to be entered as first or only entry into the \/etc\/resolve.conf file, as follows (here assuming a simplified single-host setup and other local DNS, such as systemd-resolved, not running concurrently):<\/p>\n\n\n\n<pre class=\"wp-block-preformatted\">echo \"nameserver 127.0.0.1\" &gt; resolv.tmp$$<br>cat \/etc\/resolv.conf &gt;&gt; resolv.tmp$$<br>sudo mv resolv.tmp$$ \/etc\/resolv.conf<\/pre>\n\n\n\n<p>In the isolated setup, the netwox tool can be used to generate a constant DNS reply always pointing to the local cloud services (again assuming localhost for simplification, and requiring a multiplexing proxy server in addition).<\/p>\n\n\n\n<pre class=\"wp-block-preformatted\">sudo netwox 104 -h router.cloud -H 127.0.0.1 -a dns.cloud -A 127.0.0.1<\/pre>\n\n\n\n<p>In the globally connected setup, an (undocumented) feature of dnsmasq can be used. This tool allows using wildcards not only to return static addresses but also to forward requests to an explicitly specified upstream server.<\/p>\n\n\n\n<pre class=\"wp-block-preformatted\">sudo dnsmasq --no-hosts --no-daemon --address=\/lambda.us-east-1.amazon.com\/127.0.0.1 --server=\/#\/UPSTREAMDNSIP<\/pre>\n\n\n\n<p>Using dnsmasq allows for specifying alternative ports (IP#port) for &#8211;server but obviously not for &#8211;address which may however be required in single-host setups as is assumed to be the default by Localstack. To support different port assignments, three choices exist. First, a multiplexing proxy server could be used which differentiates based on HTTP headers as described above. Second, CNAMEs could be used in conjunction with virtual host-based port forwarding (e.g. using httpd&#8217;s <a href=\"https:\/\/httpd.apache.org\/docs\/current\/mod\/mod_proxy.html\">ProxyPass<\/a> statements), however the CNAME support in dnsmasq is rather limited. The third alternative would be virtual IP addresses in conjunction with static port forwarding via iptables, eliminating the need for user-space tools but requiring a more sophisticated system setup. The last alternative works today, does not lead to bottlenecks, and does not require further active system components.<\/p>\n\n\n\n<p>Performance-wise, a back-of-the-envelope comparison with a quick and dirty experiment reveals that with both tools, a host query requires on average 7.7 milliseconds, not revealing any significant disadvantage of using the substring-matching dnsmasq tool over the constant-reply netwox equivalent.<\/p>\n\n\n\n<p>The key ingredient of the virtual IP address setup is to assign one per Localstack service, with IP addresses roughly matching the Localstack mock service port numbers to avoid any confusion during debugging. For each service, all regions (and the region-less endpoint) need to be set up. The main instructions to realise this setup are given here:<\/p>\n\n\n\n<pre class=\"wp-block-preformatted\"># e.g. port=4574 for Localstack's AWS Lambda mock service<br>ip=10.10.0.$(($port-4500))<br>sudo ip addr add $ip\/32 dev lo<br>sudo iptables -t nat -A OUTPUT -o lo -p tcp -m tcp -d $ip --dport 443 -j DNAT --to-destination 127.0.0.1:$port<br>sudo iptables -t nat -A POSTROUTING -o lo -m addrtype --src-type LOCAL --dst-type UNICAST -j MASQUERADE<\/pre>\n\n\n\n<p>In this setup, any request to the virtual IP address 10.10.0.74:443 is routed within the local network device (lo) to 127.0.0.1:4574, and together with dnsmasq on the front and Localstack on the back, commands such as &#8216;aws lambda list-functions&#8217; will interact with the mock Lambda service without requiring further configuration.<\/p>\n\n\n\n<p>In our research, we are now using one such emulation environment to evaluate the behaviour of cloud services and applications which build upon AWS services, and will report about the results in the future.<\/p>\n<div class=\"pt-sm\">Schlagw\u00f6rter: <a href=\"http:\/\/blog.zhaw.ch\/splab\/tag\/aws\/\">aws<\/a>, <a href=\"http:\/\/blog.zhaw.ch\/splab\/tag\/emulation\/\">emulation<\/a>, <a href=\"http:\/\/blog.zhaw.ch\/splab\/tag\/networking\/\">networking<\/a>, <a href=\"http:\/\/blog.zhaw.ch\/splab\/tag\/private-cloud\/\">private cloud<\/a>, <a href=\"http:\/\/blog.zhaw.ch\/splab\/tag\/programming\/\">programming<\/a><br><\/div>","protected":false},"excerpt":{"rendered":"<p>While hybrid, multi- and cross-cloud applications are on the rise, even for scenarios in which purely public cloud deployments are planned, having an equivalent private cloud stack available is useful in many ways. With the relative portability of popular open source cloud stacks, this is rather trivial to accomplish. For many large cloud providers, there [&hellip;]<\/p>\n","protected":false},"author":203,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"ngg_post_thumbnail":0,"footnotes":""},"categories":[4],"tags":[18,70,71,69,48],"features":[],"class_list":["post-685","post","type-post","status-publish","format-standard","hentry","category-research","tag-aws","tag-emulation","tag-networking","tag-private-cloud","tag-programming"],"yoast_head":"<!-- This site is optimized with the Yoast SEO Premium plugin v27.2 (Yoast SEO v27.2) - https:\/\/yoast.com\/product\/yoast-seo-premium-wordpress\/ -->\n<title>Evaluation of AWS &quot;Private Cloud&quot; options for serverless computing - Service Prototyping Lab<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/blog.zhaw.ch\/splab\/2019\/05\/21\/evaluation-of-aws-private-cloud-options\/\" \/>\n<meta property=\"og:locale\" content=\"en_GB\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Evaluation of AWS &quot;Private Cloud&quot; options for serverless computing\" \/>\n<meta property=\"og:description\" content=\"While hybrid, multi- and cross-cloud applications are on the rise, even for scenarios in which purely public cloud deployments are planned, having an equivalent private cloud stack available is useful in many ways. With the relative portability of popular open source cloud stacks, this is rather trivial to accomplish. For many large cloud providers, there [&hellip;]\" \/>\n<meta property=\"og:url\" content=\"https:\/\/blog.zhaw.ch\/splab\/2019\/05\/21\/evaluation-of-aws-private-cloud-options\/\" \/>\n<meta property=\"og:site_name\" content=\"Service Prototyping Lab\" \/>\n<meta property=\"article:published_time\" content=\"2019-05-21T08:16:52+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2019-05-21T10:47:39+00:00\" \/>\n<meta name=\"author\" content=\"Josef Spillner\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Josef Spillner\" \/>\n\t<meta name=\"twitter:label2\" content=\"Estimated reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"7 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\/\/blog.zhaw.ch\/splab\/2019\/05\/21\/evaluation-of-aws-private-cloud-options\/#article\",\"isPartOf\":{\"@id\":\"https:\/\/blog.zhaw.ch\/splab\/2019\/05\/21\/evaluation-of-aws-private-cloud-options\/\"},\"author\":{\"name\":\"Josef Spillner\",\"@id\":\"https:\/\/blog.zhaw.ch\/splab\/#\/schema\/person\/33a5227c6cc1fa3329279d33c3cc440e\"},\"headline\":\"Evaluation of AWS &#8220;Private Cloud&#8221; options for serverless computing\",\"datePublished\":\"2019-05-21T08:16:52+00:00\",\"dateModified\":\"2019-05-21T10:47:39+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\/\/blog.zhaw.ch\/splab\/2019\/05\/21\/evaluation-of-aws-private-cloud-options\/\"},\"wordCount\":1246,\"commentCount\":0,\"keywords\":[\"aws\",\"emulation\",\"networking\",\"private cloud\",\"programming\"],\"articleSection\":[\"Research\"],\"inLanguage\":\"en-GB\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\/\/blog.zhaw.ch\/splab\/2019\/05\/21\/evaluation-of-aws-private-cloud-options\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/blog.zhaw.ch\/splab\/2019\/05\/21\/evaluation-of-aws-private-cloud-options\/\",\"url\":\"https:\/\/blog.zhaw.ch\/splab\/2019\/05\/21\/evaluation-of-aws-private-cloud-options\/\",\"name\":\"Evaluation of AWS \\\"Private Cloud\\\" options for serverless computing - Service Prototyping Lab\",\"isPartOf\":{\"@id\":\"https:\/\/blog.zhaw.ch\/splab\/#website\"},\"datePublished\":\"2019-05-21T08:16:52+00:00\",\"dateModified\":\"2019-05-21T10:47:39+00:00\",\"author\":{\"@id\":\"https:\/\/blog.zhaw.ch\/splab\/#\/schema\/person\/33a5227c6cc1fa3329279d33c3cc440e\"},\"breadcrumb\":{\"@id\":\"https:\/\/blog.zhaw.ch\/splab\/2019\/05\/21\/evaluation-of-aws-private-cloud-options\/#breadcrumb\"},\"inLanguage\":\"en-GB\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/blog.zhaw.ch\/splab\/2019\/05\/21\/evaluation-of-aws-private-cloud-options\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/blog.zhaw.ch\/splab\/2019\/05\/21\/evaluation-of-aws-private-cloud-options\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Startseite\",\"item\":\"https:\/\/blog.zhaw.ch\/splab\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Evaluation of AWS &#8220;Private Cloud&#8221; options for serverless computing\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/blog.zhaw.ch\/splab\/#website\",\"url\":\"https:\/\/blog.zhaw.ch\/splab\/\",\"name\":\"Service Prototyping Lab\",\"description\":\"A Blog of the ZHAW Zurich University of Applied Sciences\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/blog.zhaw.ch\/splab\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-GB\"},{\"@type\":\"Person\",\"@id\":\"https:\/\/blog.zhaw.ch\/splab\/#\/schema\/person\/33a5227c6cc1fa3329279d33c3cc440e\",\"name\":\"Josef Spillner\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-GB\",\"@id\":\"https:\/\/secure.gravatar.com\/avatar\/c57d7019e91373902c08eac230e003cb4f8498ecf68c9d119e9ecb82fdf6c400?s=96&d=mm&r=g\",\"url\":\"https:\/\/secure.gravatar.com\/avatar\/c57d7019e91373902c08eac230e003cb4f8498ecf68c9d119e9ecb82fdf6c400?s=96&d=mm&r=g\",\"contentUrl\":\"https:\/\/secure.gravatar.com\/avatar\/c57d7019e91373902c08eac230e003cb4f8498ecf68c9d119e9ecb82fdf6c400?s=96&d=mm&r=g\",\"caption\":\"Josef Spillner\"},\"description\":\"Head of the Service Prototyping Lab. Research on distributed systems and application computing paradigms. Senior lecturer at Zurich University of Applied Sciences.\",\"url\":\"https:\/\/blog.zhaw.ch\/splab\/author\/spio\/\"}]}<\/script>\n<!-- \/ Yoast SEO Premium plugin. -->","yoast_head_json":{"title":"Evaluation of AWS \"Private Cloud\" options for serverless computing - Service Prototyping Lab","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/blog.zhaw.ch\/splab\/2019\/05\/21\/evaluation-of-aws-private-cloud-options\/","og_locale":"en_GB","og_type":"article","og_title":"Evaluation of AWS \"Private Cloud\" options for serverless computing","og_description":"While hybrid, multi- and cross-cloud applications are on the rise, even for scenarios in which purely public cloud deployments are planned, having an equivalent private cloud stack available is useful in many ways. With the relative portability of popular open source cloud stacks, this is rather trivial to accomplish. For many large cloud providers, there [&hellip;]","og_url":"https:\/\/blog.zhaw.ch\/splab\/2019\/05\/21\/evaluation-of-aws-private-cloud-options\/","og_site_name":"Service Prototyping Lab","article_published_time":"2019-05-21T08:16:52+00:00","article_modified_time":"2019-05-21T10:47:39+00:00","author":"Josef Spillner","twitter_card":"summary_large_image","twitter_misc":{"Written by":"Josef Spillner","Estimated reading time":"7 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/blog.zhaw.ch\/splab\/2019\/05\/21\/evaluation-of-aws-private-cloud-options\/#article","isPartOf":{"@id":"https:\/\/blog.zhaw.ch\/splab\/2019\/05\/21\/evaluation-of-aws-private-cloud-options\/"},"author":{"name":"Josef Spillner","@id":"https:\/\/blog.zhaw.ch\/splab\/#\/schema\/person\/33a5227c6cc1fa3329279d33c3cc440e"},"headline":"Evaluation of AWS &#8220;Private Cloud&#8221; options for serverless computing","datePublished":"2019-05-21T08:16:52+00:00","dateModified":"2019-05-21T10:47:39+00:00","mainEntityOfPage":{"@id":"https:\/\/blog.zhaw.ch\/splab\/2019\/05\/21\/evaluation-of-aws-private-cloud-options\/"},"wordCount":1246,"commentCount":0,"keywords":["aws","emulation","networking","private cloud","programming"],"articleSection":["Research"],"inLanguage":"en-GB","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/blog.zhaw.ch\/splab\/2019\/05\/21\/evaluation-of-aws-private-cloud-options\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/blog.zhaw.ch\/splab\/2019\/05\/21\/evaluation-of-aws-private-cloud-options\/","url":"https:\/\/blog.zhaw.ch\/splab\/2019\/05\/21\/evaluation-of-aws-private-cloud-options\/","name":"Evaluation of AWS \"Private Cloud\" options for serverless computing - Service Prototyping Lab","isPartOf":{"@id":"https:\/\/blog.zhaw.ch\/splab\/#website"},"datePublished":"2019-05-21T08:16:52+00:00","dateModified":"2019-05-21T10:47:39+00:00","author":{"@id":"https:\/\/blog.zhaw.ch\/splab\/#\/schema\/person\/33a5227c6cc1fa3329279d33c3cc440e"},"breadcrumb":{"@id":"https:\/\/blog.zhaw.ch\/splab\/2019\/05\/21\/evaluation-of-aws-private-cloud-options\/#breadcrumb"},"inLanguage":"en-GB","potentialAction":[{"@type":"ReadAction","target":["https:\/\/blog.zhaw.ch\/splab\/2019\/05\/21\/evaluation-of-aws-private-cloud-options\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/blog.zhaw.ch\/splab\/2019\/05\/21\/evaluation-of-aws-private-cloud-options\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Startseite","item":"https:\/\/blog.zhaw.ch\/splab\/"},{"@type":"ListItem","position":2,"name":"Evaluation of AWS &#8220;Private Cloud&#8221; options for serverless computing"}]},{"@type":"WebSite","@id":"https:\/\/blog.zhaw.ch\/splab\/#website","url":"https:\/\/blog.zhaw.ch\/splab\/","name":"Service Prototyping Lab","description":"A Blog of the ZHAW Zurich University of Applied Sciences","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/blog.zhaw.ch\/splab\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-GB"},{"@type":"Person","@id":"https:\/\/blog.zhaw.ch\/splab\/#\/schema\/person\/33a5227c6cc1fa3329279d33c3cc440e","name":"Josef Spillner","image":{"@type":"ImageObject","inLanguage":"en-GB","@id":"https:\/\/secure.gravatar.com\/avatar\/c57d7019e91373902c08eac230e003cb4f8498ecf68c9d119e9ecb82fdf6c400?s=96&d=mm&r=g","url":"https:\/\/secure.gravatar.com\/avatar\/c57d7019e91373902c08eac230e003cb4f8498ecf68c9d119e9ecb82fdf6c400?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/c57d7019e91373902c08eac230e003cb4f8498ecf68c9d119e9ecb82fdf6c400?s=96&d=mm&r=g","caption":"Josef Spillner"},"description":"Head of the Service Prototyping Lab. Research on distributed systems and application computing paradigms. Senior lecturer at Zurich University of Applied Sciences.","url":"https:\/\/blog.zhaw.ch\/splab\/author\/spio\/"}]}},"_links":{"self":[{"href":"https:\/\/blog.zhaw.ch\/splab\/wp-json\/wp\/v2\/posts\/685","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.zhaw.ch\/splab\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.zhaw.ch\/splab\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.zhaw.ch\/splab\/wp-json\/wp\/v2\/users\/203"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.zhaw.ch\/splab\/wp-json\/wp\/v2\/comments?post=685"}],"version-history":[{"count":14,"href":"https:\/\/blog.zhaw.ch\/splab\/wp-json\/wp\/v2\/posts\/685\/revisions"}],"predecessor-version":[{"id":709,"href":"https:\/\/blog.zhaw.ch\/splab\/wp-json\/wp\/v2\/posts\/685\/revisions\/709"}],"wp:attachment":[{"href":"https:\/\/blog.zhaw.ch\/splab\/wp-json\/wp\/v2\/media?parent=685"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.zhaw.ch\/splab\/wp-json\/wp\/v2\/categories?post=685"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.zhaw.ch\/splab\/wp-json\/wp\/v2\/tags?post=685"},{"taxonomy":"features","embeddable":true,"href":"https:\/\/blog.zhaw.ch\/splab\/wp-json\/wp\/v2\/features?post=685"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}