Michel Burger discusses extending cloud computing to the edge by deploying microservices and other cloud-native technologies closer to endpoints and data sources. He outlines how software and computing models have evolved over time from mainframes to client-server architectures to modern cloud-native approaches. Burger also discusses principles for building cloud applications including designing for failure, scaling, and managing state.

1. extending cloud computing to the edge
Michel Burger
CTO

2. A personal journey
CSF
Service Syndication
Web Technology Pioneer
Web Service Interface on top of telecommunication equipment
Web Services and Pervasive Systems
A Path towards pervasive computing: A network approach
Device Broker (Device as a service)
User as a service
Distinguished Engineer
Vodaplex, GSMA One Identity,MEC
TMF Distinguished Fellow
Micro Gateway, Equinix Cloud Exchange
Edge Cloud Engine back end support

3. Software is evolving everything

4. 1970-80: Assembler and developing compilers vs. high level language(s)
1980-90: Databases vs. software package (structured data)
1990-2000: Developing from scratch vs. using app server/middleware (ESB)
2000-2010: Scalable infrastructure vs. IT cloud resources (ala Amazon)
2010-2020: Big Data solution vs. a cloud solution; app service/middleware
vs.APIs and PaaS (ala Google appengine, force.com…)
2020-…: Cluster management vs Kubernetes/Istio; deployment infrastructure
vs deployment as a service; microservice (cloud edge) vs client/server
Evolution of core developers versus the others

5. Subroutines: make the code more readable
Pitfall: exiting the subroutines via GOTO…..
Local Libraries: benefit from the work done by others on the same environment
Pitfall: circular reference on import
Remote Libraries (Object): benefit from the work of others
Pitfall: hiding distribution (CORBA…)
Web Services: internal accessible Services
Pitfall: too complex
APIs: consuming a resource without having to worry on how it is implemented
Pitfall: clear understanding of differences between implementation and
exposure
Evolution of software structures

6. Evolution of the computing model
OS
Application
Resources
Disk-Centric Computing
Disk OS’s
DBMS
Spreadsheet
Word Processor
Device Drivers
(disk, tape, serial)
From 1950’s
Net-Centric Computing
TCP / IP
Telnet
FTP
HTTP
SMTP
Network Drivers
(3Com, Cisco,...)
From 1980’s
API-Centric Computing
API exposure
Mobile App
Multi Screen App
Client Mashup
Cloud Mashup
Service
Implementing API
From 2000’s
Agent-centric Computing
Analytics based
Agents
Fluid logic
Non-Imperative
Logistics
Devices/
Basic Services
(implemented as
agents)
Future

7. Disruption: Pressure on IT
IT
Digital
Assets
CMO asks for:
Mobile Apps, Partner Onboading
CFO requests:
“Lean”, Focus on core competencies
API
Data
Digital service ecosystem
where
services are internal or
external
Horizontalization where
every companies become a
service provider
Hybrid Cloud where
service provider is irrelevant
Everybody wants:
Consumerization on IT services

8. Build for Failure: Think someone yanking a VPC without warning – while you are working on it. When you start it back up again – it
should continue working without a hitch, no loss of customer data. DON’T STORE ANY STATE ON THE LOCAL MACHINE!
Build for Infinite Scale: Always assume there will be multiple instances of your code running on many machines.
Build for Latency: Network is slow, services are slow. Build your components not to be tied to state (I.E. Don’t hold state in memory
or local disk – unless you can recover it after a failure) whilst you are waiting and also use APM down to the last IO port (in most of our
cases a call into the network).
Build for Brewer Conjecture: You can have at most 2 of Consistency, Availability & Tolerant Network Partitions. Cloud services
don’t demonstrate eventual consistency. Deal with it in code.
Build for the Cloud: when you use cloud services – there are no guarantees. You are not guaranteed that you will get all the data,
you are not guaranteed that you will get them in order, you are not guaranteed anything! Now build your app to work with this.
Build with clean Interfaces: Don’t build with RPC Hangover. Build clean hierarchical REST interfaces using the resource model.
Build Probabilistically: Do we absolutely need to be a 100% accurate? Really? Are you sure? Positive? Use Bloom filters and caches
where possible.
Build to manage: Apply the FCAPS model to your services, other services/platform will need it.
Build to Cache: think HTTP caching and multiple layers of it. All GET operations must be cacheable.
Build to be Idempotent: same operation twice should not put your system in an inconsistent state.
Build for geo: build your component knowing that you could have multiple geographical partitions of data that you might have to use
sitting in different parts of the world.
Build for Data: make sure that what you write generates monetizable data.
Cloud architecture principles

9. Load based
Trigger: load changes (up or down)
Action: solution makes a request to an explicit broker for new IT resources or to release IT resources (request criteria is location and
resource type)
Resilience
Trigger: IT resource not available
Action: solution makes a request to an explicit broker for new IT resources as a replacement
Expansion of trigger and request criteria
Trigger: going beyond load and availability (eg: heat)
Action: solution makes a request to an explicit broker for new IT resources or to release IT resources (request criteria not only based on
location and resource type : eg heat).
Expansion to the implicit broker
Trigger: same as level 3
Action: the response is not limited to a specific data center and the resource returned can be within a different data center
Analytic based triggers and analytic based implicit requests
Trigger: analytics defines when to trigger the solution
Action : the solution makes a request to an implicit broker with a wide range of criteria and the IT resource returned is based on analytics
criteria
Evolution of cloud elasticity

10. Disruption: everything is getting easier
To Design
To Deploy
To Operate
API and languages (node.js)
Virtualization and Containers
Consumerization(API, Hybrid cloud)
and Elasticity

11. Disruption: everything is getting smarter
Data
From the consumers
From the services
From IT
From the network
Value
To Design
To Deploy
To Operate
API and languages (node.js)
Virtualization and Containers
Consumerization(API, Hybrid cloud)
and Elasticity

12. Microservice blueprint
Microservice
API
Database
Stream
Logs
Info
Publish/Subscribe or Queue
Events-out
Events-in
Other
API
(internal
or
external)
API Calls using
System tokens
Load Balancer
API Gateway
Cluster
management
agent
Sidecar
To expose API
to 3rd parties
Cluster
manager
Discovery
API
to
other
instances
in
the
cluster
API Calls using system tokens
As a library or external process to
handle the microservice as part of
a cluster of microservices
As a library or external process
to perform routing, control,
monitoring and micro API
gateway operations

13. Immutable infrastructure principles
Automation: Automate the setup and deployment for every part and
every layer of the infrastructure
No Partial Update: Never change any part of the system once it is
deployed. If it needs to be changed, deploy a new system.
Rolling Upgrade: Deployments will be done as rolling upgrades, and
therefore:
All database schema changes must be backwards compatible at least up to 2
versions
No Direct Access: Instances are headless with no SSH or direct access.
Automate sending all debug logs, etc. to centralized services

14. Microservice do and don’t
API First API is not SQL, generating a nice swagger file from code
does not really help
All APIs are secure via token No public/private APIs, avoid API gateway monolith
Configuration via environment variables or API No manual deployment or human access to production
machines
Microteam organization No technology transfer
Stick to one stack No rushing to the new shiny objects (Cargo cult syndrome),
polyglot systems are difficult to maintain
Test early Over testing and relying on test for quality
Logs must tell a story Breakpoints
Qualify your data (logs, info, events) No share of info between microservices except via API or
events, avoid data monolith
Horizontal scalability (Custer management) Scalability is not an option

15. System view (example)
1
Real Time
Communication
Contextual
Information
Charging &
Billing
Identity &
Authentication
Data & Info
Mgmt
Network
Optimization
Send Message Device Status Charge-to-bill Single Sign On Device management Network Load
Receive Message Device Capabilities Charge the provider Anonymous Customer
Reference
Provisioning
- Internal
- External
Best time of day
Call Control Location via Terminal Tariff Information Generic Validation Provisioning
Notification
- Internal
- External
Pre-load content
to CDN
Call Notification Device Connection Charge Notification Support of OpenID Address Book Push Notification
Update Call
- Add party
- Add medium
Location via Network Billing History Support of OAuth Backup
Transcoding
(Media Rendering)
Device Status
Notification
Payment
(Credit Card Processing)
Authentication for
Wifi Access
Resource Discovery
Transcoding
Notification
Location Notification
(Zone Based)
Payment
Configuration
Product Catalogue
- Internal
- External
User Profile Order Handling
User Profile
Notification
Order Handling
Notification
Device Connection
Notification
Product Catalogue
Notification
M-Data
(analytics, advertisement)
Sim Management
χ y
x
API Exposed via the Vodafone Platform
α N
β N
β RA
MN
β A
β A
α A
MRA
α A
β A
MRA
MRA
α A
M A
M
β A
α
M
α
1
2(1) 3 1 2
2 1 2 2(1)
2 2(1) 3 2
2 1 2 2
2(1) 1
Currently Available
Available by end of FY 12/13
Future Goals
3+
3+
MAN
MAN
MN
Mondrian
Update
NFC
Location Enabler
RCS-e
RCS-e
RCS-e
Smart Network
Smart Network
Messaging
Messaging
Mondrian
Mondrian
Mondrian
Location Enabler Mondrian
Mondrian
Mondrian
Mondrian
Mondrian
Mondrian Mondrian
Mondrian
Mondrian
Mondrian
Mondrian
Mondrian
Smart Network
Smart Network
M
Smart Network
Mondrian ER
ER Identity Mgmt
Identity Mgmt
Identity Mgmt
Identity Mgmt
Identity Mgmt
Identity Mgmt
Mondrian
Smart Charging
M-Analytics
Update
Content Proposition
Content Proposition
α N
1
2(1)
βRA
2
3+
3+
3+
3+
3
1
2
Beta5 project wave
Level of Interoperability:
- Redirection
- Application
- Network
Exposure Phase
β A
Parlay X (90%)
GSMA ONE API
Modelled on Parlay
X, SID, eTOM

16. Infrastructure abstraction: to go beyond virtualization to provide service with a set of APIs on how to consume basic IT
resources (Storage, Computing, Queuing, Network)
Federated Identity: based on open standard (OpenID connect, OauthV2), to deal with identity and authorization of
Subscribers, Employee and Partner for different legacy systems and handle identity from 3rd party service
Federated Profile: to act as a discovery of all data resources for specific top level entities (like users) as entry points to
distributed graphs of data
Consistent Operation Management (Distributed Transaction Management): to provide the infrastructure, top level APIs
and API specifications for system components to deal with distributed transactions for consistent operations like user
or service lifecycle
Eventually Consistent Operation Management (High Performance Notification/Event Management): to handle
eventually consistent real-time, near real-time distributed notification/event system for services using the notion of
inbox, outbox queues
Analytics: to handle via a multi-structured stream, all data extracted from every services/system components (as source
of data) and provide thru API is a way to consume the data from the stream
Exposing service APIs in the proper context: services are about API and not just end to end experience
Pillars of a microservice based platform

17. Federated Identity
Becoming an Identity Provider -> OpenId Connect)
• Consent Management
Federating internal identities -> (OauthV2)
Single Sign-On

18. • Entry point of a web graph via Top Level Entity
• Indicates the location of user’s disparate data resources
• Combines multiple resources into one view of data across multiple systems
Federated profile
…

19. Gold mining is about dirt management
0.05 ounces/ton
Analytics analogy I

20. About 11850 Amps to
generate around 8.4 Tesla
fields (about 150000 times the
earth magnetic field) but they
operate at low Voltage
A lot of what LHC is about is electricity flow management
Analytics Analogy II

21. Analytics is like LHC combined with gold extraction
• Huge amount of data -> 6.6 Zbytes/year by 2016 (Cisco Cloud Index)
• Big flow of data -> 400TB/day (Facebook)
• LHC generates 10-15 Petabytes/year of data for each experiment
Analytics

22. SSD memory (Violin), Redis
S3, Glacier
Snowflake, Athena, Redshift
Kinesis, Kafka
• Buffering, Routing, Filtering
• Structured/Unstructured store
• Event Collector
• Batch Process/Multi Structure Stream
• Multi Stage Store/Process
• Memory, disk, tape, archive based Non
Real-time
Real-time
Low
level
Semantic
Rich
Semantic
Cheap
Storage
High
Efficient
Storage
Analytic architecture
API
Data card
Sim Card
Content
Services
Knowledge
References
Applications
Social Networks
Connected Things
(Consumer,
Enterprise)
Connected Devices
Network Core
IT Infrastructure
RAN
Premise
Gateway
• Many different data structures
• Many different ways to extract the data
• Many different locations (even for the same type of data)
• Batch and Realtime based
• Buffered or stream
• Correlation parameters
Report Statistics
Data as a Service
Graph Network
Analysis
Neural Network
Analysis
Sources
Stream
Machine Learning
• Structured Buffering
- Proprietary
- Graph
- Neural Network
- Relational
• Unstructured Buffering
- Streaming
• Taping at Source
• Taping on Stream
• Consumption to
Source

23. Cloud analogy
Collocation Centralization of production
Decentralization of consumption
Mass distribution of production
and consumption
Collocation is back
Dam used as cheap storage

24. Evolution of cloud: edge cloud
‣ edge cloud enables new device types to act as
servers
‣ routers, gateways, mobile devices, game consoles
‣ serverless microservices may run on any device
‣ edge cloud is local
‣ closer to the user, closer to the data
‣ peer to peer communication
‣ edge cloud is multi-server
‣ apps decide where their “backend” services run
‣ central cloud, local machine
‣ edge cloud is distributed and dynamic
‣ edge servers may be ephemeral, mobile
‣ edge cloud scales
‣ new nodes add more resources at the edge

25. Disruption: from client/server to application/service
The Web normalized the client-server approach in designing and deploying solutions:
Microservices (cloud or edge) exposing API and deployed on demand at the right place are
normalizing the ability to create solutions by composing services:
Server
Client
device network cloud
application µ
service
µ
service
µ
service
µ
service
µ
service µ
service
device network cloud

26. Disruption: from star to hybrid topology
application
µ
service
µ
service
device
application
µ
service
µ
service
application
µ
service
µ
service
µ
service
network
µ
service
µ
service µ
service
cloud
Devices are not attached to the cloud, but
for an extension of the cloud at the edge
New types of clusters are becoming
important to manage:
• network
• proximity
• account

27. Edge cloud principles
• Meritocracy: all nodes can participate but take different roles based on
their merit
• Decentralised discovery: nodes discover each other based on scopes:
network, proximity & account
• Clustering: based on scopes network, proximity & account
• Microservice communication: nodes can communicate directly at
microservice level
• Dynamic resource instantiation: resources are made available only as
needed
• Independence: nodes can communicate regardless of operating
system, network, location

28. central cloud edge cloud
an edgeEngine & edgeBackend to enable devices to act as cloud servers.
a pragmatic approach to edge cloud
edgeEngine
• downloadable SDK for most
operating systems.
• devices can act as cloud
severs to other devices.
• devices can form clusters and
share resources.
edgeBackend
• backend for global
management, registration,
authorization, authentication
and security.