This document provides an introduction to APIs and microservices. It discusses how digital transformation is forcing businesses to change how they operate and engage with customers. Microservices break applications into small, independent services that work together. APIs act as the public interface of microservices. Well-designed microservices and APIs can help businesses achieve greater agility, faster delivery, and ability to manage complexity at scale.
The document discusses four keys to securing distributed industrial internet of things (IIoT) systems: 1) using a decentralized architecture rather than a centralized one, 2) implementing access control, 3) not relying solely on TCP and transport layer security, and 4) ensuring interoperability through open architectures and standards. It provides examples of how RTI's Data Distribution Service approach addresses these keys and secures critical infrastructure like power grids.
This document discusses using the Data Distribution Service (DDS) and RTI Connext DDS for building scalable, distributed systems for the Industrial Internet of Things (IIoT). DDS provides data-centric publish-subscribe communication that supports real-time integration of sensors, controllers and applications. It enables seamless data sharing across networks, platforms and locations. RTI is a leading provider of DDS middleware and has experience integrating DDS into large industrial and military systems.
This document discusses software defined networking (SDN) based load balancing. It describes how SDN allows load balancers to be configured through APIs instead of complex network configurations, enabling automation. An example API call is shown to create a load balancing pool. SDN load balancers can be flexibly deployed at different sizes for high performance, per-pod, or per-application use. An example is given of integrating SDN load balancing with OpenStack through Neutron LBaaS.
The webinar discussed interoperability and portability for cloud computing based on the Cloud Standards Customer Council's guide version 2.0. It covered definitions of interoperability, application portability, and data portability. Challenges to interoperability and portability were presented for different cloud service models. Recommendations were provided for different cloud usage scenarios to improve interoperability and portability. Open standards that can help were also listed.
For many, web-scale IT is an alien and drastic approach being met with fear and resistance. So the first question for any organization should be; what is it? Cameron Haight, Gartner’s chief of research for infrastructure and operations, coined the term “Web-scale IT” earlier 2014 as a way to describe the new ways organizations leverage technology to provide their customers with content quickly and at massive scale.
1) The document discusses using the Data Distribution Service (DDS) standard and Connext DDS middleware to develop mission-critical systems with Ada. DDS handles connectivity and allows applications to communicate in a loosely coupled publish-subscribe manner.
2) Developing applications directly with traditional inter-process communication approaches is expensive and ties applications to specific communication mechanisms. DDS simplifies application logic and reduces development and integration costs.
3) DDS supports real-time and safety-critical systems and has been used for systems like avionics and defense applications. It interfaces with Ada through code generation from IDL definitions.
The document discusses trends in cloud network technology, deployment, and security. It notes a shift towards more private and localized public clouds with hybrid models. SDN is seen as key for integrating cloud and network virtualization, with VxLAN becoming preferred for overlay networks. New requirements include rebuilding security zones as network borders disappear and providing service-centric security policies. Trends involve policy-aware security across layers using firewalls, sandboxing, reputation systems and big data to defend against advanced threats.
Unified Analytics in GE’s Predix for the IIoT: Tying Operational Technology t...Altoros
Learn how to achieve holistic operational visibility into IIoT business environments by correlating the data from Operational Technology and IT, and organizing it as a single pane of glass in accordance with business processes.
Integrating DDS into AXCIOMA, the component approachRemedy IT
This document discusses integrating the Data Distribution Service (DDS) into AXCIOMA, a software suite that combines 11 open standards. It describes how DDSX11 abstracts the DDS vendor API to simplify programming and testing. Components use interaction patterns like request/reply and publish/subscribe to interact over DDS. The document provides an example of generating types from IDL and implementing a publisher component that writes DDS samples.
On-Demand: http://ecast.opensystemsmedia.com/474
GE, Cisco, AT&T, Intel and IBM recently established the Industrial Internet Consortium (IIC) at the Object Management Group (OMG) standards body. OMG is the world's largest system software standards organization, responsible for the UML modeling language and DDS data-centric middleware standards. Attend this webinar and find out how DDS can drive the Industrial Internet. At the OMG, the IIC will focus on standards relevant to the Industrial Internet, the branch of the Internet of Things that enables intelligent distributed machines. The IIC will break down technology silos to improve integration of the physical and digital worlds. RTI, the market-leading DDS vendor, provides the key communications infrastructure that enables smart machines in the Industrial Internet. This webinar will review the technology and examine real-world use cases for RTI DDS in the Industrial Internet across several industries, including medical, energy, aviation and automotive.
Speaker: Dr. Stan Schneider, Chief Executive Officer, RTI
Stan Schneider is a recognized expert in the development and integration of distributed real-time systems. He founded RTI to develop productivity tools for the real-time marketplace. Under his guidance, RTI has grown from inception to a multinational business with offices throughout North America and Europe.
Stan completed his Ph.D. in Electrical Engineering and Computer Science at Stanford University. He holds a BS in Applied Mathematics (Summa Cum Laude) and an MS in Computer Engineering from the University of Michigan.
The document discusses autonomous vehicle design and RTI's expertise in autonomy. It begins by outlining the challenges of autonomous vehicle technical including rapid evolution, complex system integration, on/off vehicle communications, perception and sensing, decision making, safety certification, and software dominance in a mechanical world. It then describes RTI's experience in various industries and standards efforts. RTI is said to have deep expertise in autonomy from its founders' background and use of its middleware to power unmanned systems. The document discusses how RTI can help with autonomous vehicle development through ensuring data availability, guaranteeing real-time response, managing complex data flows and states, easing system integration, building in security, making deployments flexible, and easing safety
Business Drivers of SDN by Paul Wiefels, Chasm GroupSDxCentral
This document discusses the transition from traditional enterprise IT systems of record to new systems of engagement. It outlines how consumer technologies like mobile, broadband, and social media have driven rapid innovation, creating expectations for more engaging experiences. This is shifting enterprise IT focus from cost efficiency to enabling new collaborative applications and real-time interactions between employees, customers and partners. It suggests infrastructure must evolve from rigid systems to agile, virtualized networks supporting these new engagement systems. Security challenges will increase as systems become more open and real-time.
The document compares OPC UA and DDS, two key protocols for industrial IoT. OPC UA is object-oriented and client-server, targeting simpler systems with device interchangeability needs. DDS is data-centric and peer-to-peer, more suitable for systems with primary software integration challenges. Both communities are working to ensure their technologies can work together, preserving investments as architectures evolve.
The document outlines Don Pearson's agenda for a presentation on MQTT for IIoT. It discusses how MQTT is well-suited as an IIoT messaging protocol due to its low bandwidth usage, TLS security, and stateful awareness. It also describes how to implement MQTT architectures with edge devices, MQTT servers, and MQTT clients like Ignition. The presentation demonstrates how Ignition and its MQTT modules can be used to migrate legacy systems and enable bidirectional communication with MQTT-enabled devices.
Data Center: New Frontiers - Clive D'Souzascoopnewsgroup
This document discusses the transformation of networking driven by trends like cloud computing, big data analytics, and the growth of digital services. It outlines how software-defined networking (SDN) and network functions virtualization (NFV) are abstracting network infrastructure and making it more flexible. The document also describes Intel's investments in open standards, reference architectures, and enabling technologies to lead the transition to virtualized and software-defined networks.
This document discusses the partnership between Microsoft Azure and GE's Predix platform for industrial IoT. For Microsoft, the partnership will help existing industrial customers build and operate IIoT solutions using Azure's capabilities in artificial intelligence, data analytics, and security. For GE, Predix will benefit from Azure's large global footprint and hybrid cloud capabilities. The combination of Predix and Azure aims to bridge the gap between operational technology and information technology for industrial customers worldwide.
This document discusses cybersecurity and data protection measures for networks. It notes that agencies prioritize prevention but may not fully protect their network data. Recommendations include selecting simple and scalable encryption solutions. Future trends involve software-defined networking and centralized security management. The document promotes Brocade security products and calls agencies to learn more about protecting network data.
The New Ignition v7.9 - See, Maintain, and Manage Your Enterprise With Ease Inductive Automation
Colby Clegg and Carl Gould, Co-Directors of Software Engineering, introduce the new Ignition v7.9. In this webinar, Colby and Carl discuss and demonstrate the new features of Ignition v7.9.
OPC UA Security: Native and Add-on Solutionsteam-WIBU
The Industrial Internet of Things has set the stage for the convergence of Operations Technology (OT) and Information Technology (IT), that is, the plant floor and the higher-level IT infrastructure. One of the many aspects of this transitional journey is represented by M2M communications.
OPC UA is a multi-platform, plug & play Information Exchange Standard for industrial smart automation and cloud networking. It standardizes communications within machines, between machines, and from machines to smart systems, securely networked with IoT architectures.
As a member of the OPC Foundation, Wibu-Systems has been an early adopter of the OPC UA standard in Industrie 4.0 projects like IUNO, the German national reference project for IT security in Industrie 4.0, S4SmartPro, the key finder prototype production line of SmartFactoryKL, and OpSit, the optimal use of smart items technologies in healthcare.
As recently pointed out in the Industrial Internet Security Framework as well, it is endpoints, i.e. the device or cloud-based components that have interfaces for network communication, that are particularly vulnerable in a world of cyber-physical systems connected to open networks. The Unified Automation ANSI C based and High Performance OPC UA SDKs, powered by CodeMeter Embedded, fully support the OPC UA defined Security Profiles and configurations and provide even stronger security for modern M2M communications. Secret information, like RSA private keys, certificates, and trust lists, is stored in a hardware secure element and protected from theft and tampering attacks. In a time when intellectual property is shifting in the value chain from hardware to software, manufacturers now also have new opportunities to capitalize on their software and offer feature-based, time-based, version-based, or pay-per-use models to scale up their offerings, expand their market share, and produce recurrent revenues.
In this presentation, we are going to navigate you through a journey of exploration that will touch upon:
* The elements of innovation in smart manufacturing
* The connection requirements for M2M in the IIoT age
* The building blocks of the OPC Unified Architecture
* Use cases that are accelerating the rise of Smart Factories
* The integration of CodeMeter in the OPC UA standard
* The OPC UA security extension for endpoints
Working with Windows, Linux, macOS, or Android? With minimal embedded controllers up to massive cloud infrastructures? OPC UA and CodeMeter are equally suited, scalable, and secure, and most of all integrated in a streamlined fashion to provide the ultimate technology in access control, authentication, and encryption.
Watch the webinar: https://youtu.be/r3CHB42OJ-o
The document discusses microservices, which break large monolithic applications into smaller, independent services. Each microservice focuses on performing a single function and communicates over the network. This allows for independent scaling, upgrades, and maintenance of services. The document outlines design principles for microservices including high cohesion, autonomy, resilience and being domain-driven. It also discusses technologies used to build microservices architectures like containers, asynchronous communication, registration and discovery, and automation tools.
This document provides an overview of microservice architecture, including its key characteristics, benefits, problems, and solutions. Microservices are small, independent services that are organized around business capabilities. They communicate through APIs and can be developed and deployed independently. Benefits include scalability, flexibility, and ease of development and testing. Challenges include configuring and monitoring distributed services. Common solutions involve service discovery, load balancing, centralized logging/monitoring, and externalizing configuration. The document also discusses architectural patterns, anti-patterns, and references further resources on microservices.
Evolving your Architecture to MicroServicesHector Tapia
Once-stable industries are rapidly being disrupted as companies move toward digitalization by embracing software at their core.
Deploying cloud-native application architectures is at the center of how these businesses are fueling their disruptive character.
Christian Posta is a principal middleware specialist and architect who has worked with large microservices architectures. He discusses why companies are moving to microservices and cloud platforms like Kubernetes and OpenShift. He covers characteristics of microservices like small autonomous teams and decentralized decision making. Posta also discusses breaking applications into independent services, shedding dependencies between teams, and using contracts and APIs for communication between services.
Are you jumping on the microservices bandwagon? When and when not to adopt micro services architecture? If you must, what are the considerations? This slidedeck will help answer a few of those questions...
The Role of Data Virtualization in an API EconomyDenodo
You can watch the webinar on demand here: https://buff.ly/2RQltuF
Digital transformation, even though a cliché, is definitely on top of every CEO's strategic initiative list. At the heart of any digital transformation, no matter the industry or the size of the company, there is an API strategy. Application programming interfaces (APIs) are the connection points between one application and another, and as such, they enable applications to build on each other, extend each other, and work with each other. Taken together, APIs represent a thriving ecosystem of developers that is showing no sign of slowing down.
Attend this webinar to learn:
• How data virtualization greatly enhances the capabilities of an API
• How data virtualization works as a service container, as a source for microservices and as an API gateway
• How data virtualization can create managed data services ecosystems in a thriving API economy
This talk was done in Feb 2020. Sergey and I co-presented at CTO Forum on Microservices and Service Mesh (how they relate, requirements, goals, best practices and how DevOps and Agile has had convergence in the set of features for Service Mesh and gateways around observability, feature flags, etc.)
Take Control of your APIs in a Microservice Architecture3scale
Microservices are a new architectural approach to modularize systems into smaller units. The benefits include that services can be adapted more rapidly to changing business demands. Application programming interfaces (APIs) are crucial in every microservice architecture (MSA) as they link up the various microservices. Key challenges of MSA are getting API security, access control and analytics right in an environment that is constantly changing. This workshop talk will show how the features of the 3scale API management platforms in combination with the Red Hat OpenShift PaaS can be leveraged to overcome these challenges.
This document discusses microservices architecture and related concepts. It begins with an overview of microservices compared to earlier SOA approaches. Key aspects of microservices covered include developing single applications as independent services, common misconceptions, principles like single responsibility, and defining appropriate service boundaries. The document also discusses messaging approaches in microservices including REST, gRPC, and asynchronous messaging. Other sections cover organizing microservices, deployment, security, data management, governance, bridging monolithic and microservice systems, and implementing a service mesh.
Business and IT agility through DevOps and microservice architecture powered ...Lucas Jellema
IT needs to run in production in order to generate business value. DevOps is among other things a way of thinking focusing on production software. A business application requires a tailor made platform to generate business value. The combination of application and its platform is a DevOps product. The DevOps team has full responsibility for that product through its entire lifecycle.
The microservices architecture promises flexibility, scalability, and optimal use of compute resources. Via independent components with well-defined scope and responsibility, interface, and ownership that are evolved and managed in an automated DevOps process, this architecture leverages current technologies and hard-learned insights from past decades.
This session defines the objectives of Business with IT, of microservices and DevOps and introduces Containers and the container platform Kubernetes as crucial ingredients for making DevOps happen.
This is a small introduction to microservices. you can find the differences between microservices and monolithic applications. You will find the pros and cons of microservices. you will also find the challenges (Business/ technical) that you may face while implementing microservices.
For a long time APIs have largely been an exercise at the edge of complexity. They provide an engaging interface to attract developers, perhaps an underlying platform to monitor their consumption, and a means for those interested in whatever drives our backend to manage that success. That type interaction demands a certain type of interaction. But what happens in a backend world of microservices? Do we really have the same API needs and flexibility concerns at the mesh that we do at the edge and how might we best address these two worlds going forward? I will present the case for edge, the case for the mesh and try to bridge whatever space we have between them: chasm or ditch.
For enterprises trying to stay ahead of the game, having a robust and fast application development program can make or break their market presence. The challenge for developers, however, is to build responsive, devise-agnostic applications in days, not months.
Global Azure 2022 - Architecting Modern Serverless APIs with Azure Functions ...Callon Campbell
The document announces an Azure event in Toronto from May 5-7th that Microsoft is sponsoring. It provides information about accessing Microsoft documentation and training resources. It also introduces the speaker, Callon Campbell, who is a Microsoft MVP in Azure and consultant specializing in app migration, modernization and Azure. The agenda covers what serverless means, demos of building serverless APIs with Azure Functions and API Management, and hosting Function apps.
[Workshop] Digital Transformation: Breaking Down Boundaries for Greater Conne...WSO2
This deck will cover the problem with running systems in isolation. how you can move away from isolated systems, an Introduction to the concept of services oriented architecture and integration hub, the benefits of sharing information and services, and will introduce the concept of API Management.
[WSO2Con EU 2017] Microservices for EnterprisesWSO2
Microservice architecture (MSA) is fast becoming a popular architecture pattern in today’s agile enterprises. Its iterative architecture and development methodologies are attracting the interest of architects who need continuous delivery to fulfill business needs. But, is every characteristic of MSA new or even pragmatic? Can MSA alone help you solve your enterprise challenges? This session will explore how middleware plays a key role in successful MSA-based implementations.
These are my summarized notes from all the microservices session I attended at QCon 2015. These sessions had tons of learning around how to scale microservices and avoid common pitfalls
SOA - Unit 2 - Service Oriented Architecturehamsa nandhini
This document discusses key concepts of service-oriented architecture (SOA), including common service delivery approaches, SOA concepts, and key SOA elements. It also covers SOA processes, principles, services, service contracts, and the technical and business benefits of implementing an SOA.
This document discusses when a service mesh may be needed and provides an overview of the current service mesh landscape. It begins with why microservices are adopted and the challenges of operating distributed applications. It then describes a maturity journey where a service mesh is not initially needed but may become useful for applications that become more complex, distributed, and interdependent. The document outlines some current major service mesh implementations and notes that the technology is still new and changing rapidly. It recommends investigating service meshes through proof of concepts but cautions that production usage requires significant resources. It profiles F5 Aspen Mesh and NGINX solutions for service meshes and microservices.
2. Contents
• Setting the scene
• Why all the talk about APIs and microservices … and business agility?
• What are microservices?
• Cohesive, decoupled services …. and a whole business culture
• What are API’s?
• The public face of a microservice ….. and a whole industry
• Summary
• It’s about business agility and competiveness at scale
4. The 3rd platform
Driven by evolution of:
• Cloud platforms and marketplaces
• Prevalence of mobile technology
• Social business
• Analytics and customer insights
A platform for rapid innovation
A platform for rapid scale
5. Digital Transformation
• Forcing a change to the way businesses operate
• How they engage with customers via multiple channels
• The speed at which they deliver products and services
• How they innovate and remain competitive
• The reliability of their operations for 24/7 operation
• Their overall resiliency and longevity
7. Microservice summary
“A way to organize teams that mimic the
structure of an organization for greater
autonomy and reduced cross-team
synchronization for the purposes of
scalability, faster solution delivery, and
ability to manage complexity at the expense
of known tradeoffs.” - Christian Posta, redhat
8. Microservice pattern
“Microservices refer to developing
functionality as a collection of
small services, each running in its
own process and accessed via a
lightweight interface, such as an
HTTP RESTFul API” - Martin Fowler
“Monolithic application has single code
base with multiple modules. Modules are
divided as either for business features or
technical features. It has single build
system which build entire application
and/or dependency. It also has single
executable or deployable binary.”
Contrast with the monolith pattern
9. Characteristics of a microservice
• Componentization via services
• Organized around business capabilities
• Products not projects
• Smart endpoints and dumb pipes
• Decentralized governance and small, cross-functional teams
• Decentralized data management
• Mature CI/CD practices
• Infrastructure automation and self-service access
• Design for failure
• Evolutionary design
- Based on James Lewis & Martin Fowler
10. Microservices in action
- Sam Newman and 3scale
Multiple tier architecture
Client Tier
Delivery Tier or
Backend-for-Frontend (BFF)
Perimeter services –
routing, authentication, etc.
Aggregation/federation tier
Services tier
11. Microservice characteristics
• PROS
• A service has a fixed focus and is relatively easy to understand
• Service can be deployed independently
• Easier to scale development teams
• No commitment to long term technology stack
• CONS
• Additional complexity of a distributed system
• Harder to test
• Data consistency (CAP theory)
• Latency and connection failures
• Operational complexity
- James Lewis & Martin Fowler
12. Aren’t microservices just SoA?
• Maybe…
• More of a subset of SoA
• More specific
• Decentralised governance
• Lighter weight
• BUT…
• Micro services represent a cultural change
Microservices
SoA
14. API?
• Application Programming Interface (API)
• The means by which one application accesses the resources of another
• Defines information that is externally accessible
• Abstracts the implementation
• It’s a contract defined via endpoints, schema and version
• Its machine readable
• It’s a product with all the developer tools and trimmings
• It’s a commodity – a source of business revenue
16. How are resources accessed?
• Depends on the approach taken
• For Internet applications they should be “of the web”
• REST style API is a common approach
• Resource representations
• XML, JSON
• Http typically used as the protocol on which RESTful APIs
are based
• Natural fit for Internet networks and resource manipulation
17. Resource endpoints
Snippets from Pure Digital Internet radio service
/users/{UserID}/favourites Add content item to user favourites
/users/{UserID}/favourites/{ID} Delete a user favourite
/users/{UserID}/favourites/{ID} Update a favourite
User favourites service
/users/{UserID}/favourites Get all user favourites
/users/{UserID}/favourites/{ID} Get a user favourite
/content/Items Get all content
items/content/Items/{ContentType} Get content items by type
/content/Items/{ContentType}/{ContentID} Get a content item
Internet radio catalogue service
18. How are resources accessed?
C
R
U
D
HTTP POST /users/{UserID}/favourites + payload
HTTP 201 status code + location
HTTP GET/users/{UserID}/favourites/{ID}
HTTP 200 status code + payload
HTTP PUT /users/{UserID}/favourites/{ID}
HTTP 200 status code
HTTP DELETE /users/{UserID}/favourites/{ID}
HTTP 200 status code
19. What does an API request look like?
Request
GET /users/{userID}/favourites Http/1.1
accept: application/vnd.imgtec.com.favourites+xml
authorization: …..
Response
HTTP/1.1 200 OK
Content-type : application/vnd.imgtec.com.favourites+xml
<Favourites>
<Link rel=“add” href=“…” type=“…”
<Favourite>
<Labels />
<ContentID />
<Name />
</Favourite>
</Favourites>
REST style HTTP Request/Response
State
transfer
Representation
Resource
Method
Add
favourites
link
20. APIs need to be secured
• Resources are not available to just anyone
• Employ Identity and access management patterns
• Identity – certificates, PSKs, username, biometrics
• oAuth2 based solutions for authentication and authorisation
• OpenID, UMA
• Federated security
• LDAP
• Channel encryption
• Typically secured using TLS
21. APIs need to scale
Y-Axis-Scaling
functional decomposition
X-Axis-Scaling
Horizontal duplication
Z-Axis-Scaling
Data partitioning
- Chris Richardson (micrservice.io), Lori MacVittie (F5)
22. But there’s always more
• Everyone is constantly looking to do more and more with less
• Same goes for APIs
• Multiple channels to market with different requirements for same API
• Applications, 3rd party services, Partners, PaaS market place, developers
• Multiple “consumers” from different domains
• Identity, authentication, authorization
• Service subscription plans
• Usage contracts, feature access, throttling
• Understanding consumer experience and usage
• Metrics and analytics
• Developer ecosystems to enable API evaluation and traction
• Management of API’s becomes problematic
23. An industry to enable API agility
• API gateways
• Control run-time access to APIs
• Decouple public access to backend servers
• Authorisation, throttling, routing, caching
• But some solutions are more sophisticated offering transformation
and aggregation capabilities
• This can be dangerous
• Developer portals and ecosystems
• Self service on boarding of developers
• Documentation, registration, API keys
• API analytics
26. It’s largely about scale and agility
• You need a culture and organisation to back the concepts
• If you can’t do monoliths then you won’t be able to do
microservices
• You need domain knowledge to model the service
decomposition and your APIs
• You need to work out latency, chatty APIs and service
orchestration
• Those who do it well will thrive in the face of competition
27. Final comment
• Are microservices actually small?
• Not really.
• Small enough, but no smaller.
32. Monolithic pattern
“Monolithic application has single code
base with multiple modules. Modules are
divided as either for business features or
technical features. It has single build
system which build entire application
and/or dependency. It also has single
executable or deployable binary.”
33. Monolithic pattern
• Typically 3 or 4 components
• (UI, Business Logic, Database & Integration)
• Run in a single process
• PROS
• Simple to develop & deploy
• CONS
• Increased complexity for developers
• Longer change cycles
• Small changes requires complete retest and deployment
• Less agile as components can’t be released independently
• Long term commitment to a technology stack
• Harder to scale
• Harder to scale development teams
• Continuous deployment gets difficult
• Can’t scale only the components you need to
• Need to replicate the whole application
• Difficult to keep modular structure
• Less well suited to reuse in hybrid service applications