Simply put, a Technology Architect is someone who is constantly surveying the technical landscape learning the more useful, relevant, and least
technically bloated technologies while also utilizing an innate intuition that leads to design patterns that incorporate many of these technologies. This is
a full-time job in the broad based technology environment of the 21st Century that cannot be a subsidiary engagement subsumed by additional in
the weeds development responsibilities. Contrary to popular belief the Agile development process has not eliminated the Architect but invigorated
this position with individuals who can constantly learn, adapt, and cooperate in a dynamically changing open-source landscape.
Do you want architectural artifacts for some or all of the ideas conveyed on my technology page?
With the need to survive in a capitalist society and a basic love of eating, any additional artifacts, knowledge, and/or creative ability of mine
must be paid for either through providing my employer
with a contract where I am the principle Architect. In the past all of my ideas have been freely conveyed with those benefiting from my 22+ years of knowledge and effort not
even recognizing where the progenitor creations that they took credit for originated. Up to a point that is fine, but when these folks accelerate
their careers on my sweat and toil only to leave me in obscurity pleading for a few scraps for sustenance - it is abundantly evident the free model
has failed miserably and must end.
My Work Style Assessment
What is Agile?
Extreme planning, not fully engaging customers by asking them upfront for their user stories is not an Agile process – it is a want-to-be impostor.
Planning each week out for a customer is not Agile.
Having users or user-proxies work up user stories so you know what they want from a system standpoint is Agile.
A cooperative state of mind needs to exist between all stakeholders. Engage your customers and users not from in a Waterfall process top down
hierarchical information stream but instead a flattened vertical pure team oriented Agile approach. Even in the initial stages of a project of
any form (including a Proof-of-Concept) user stories information elicitation from the user is essential. A collaborative determination of
what are the primary user specific desires that are the drivers of the project must be understood before presenting anything to the paying customer.
Any project where weekly planning is necessary is nothing but a 20th Century process that will waste time and yield failure. Real Agile shops
do not engage in continuous fine-grained planning that subsumes the entire engagement in a culture where preparation, documentation, and
architectural artifacts are preeminent over logical united action that kindles results that meet user system expectations in each and every
What is the burn-down or work remaining out of the backlog of user stories? Are you providing meaningful application functionality that is
fully tested and production ready after each Sprint? This is what is important from an Agile process perspective – NOT megabytes of documentation
that no one will read. Locate your Agile tool of choice like
Jira and do not
waste precious intellectual cycles on extreme planning for in a dynamically changing world plans are static slices of time that can never reflect reality.
A top down initial planning of everything in detail, having the customer sign-off on this plan, passing this plan with artifacts on to developers,
and not fully requiring user or user-proxies to provide user stories – whatever you call it this top-down process is not Agile. Involving the users
or user-proxies in non-technical discussion points of their user stories that can become more detailed as progress is made iteration after iteration
fulfilling these user stories - is Agile.
This brings us back to the importance of having real users, not managers, or at least proxy users who can help you understand whether they even
like the current systems that you are attempting to create or refactor. Having real users is an essential ingredient of meeting the expectations
of your customer because ultimately the user is the real customer of any application not those who believe they fully understand what the user wants.
If the user(s) were never asked their opinions of a system how can a manager or someone else know how the user(s) feel about a current application
that is undergoing redesign or an entirely new proposed system? Never assume you understand anything about your user(s) until you ask them questions!
Option 1: REST API Microservices FaaS
Three-Tier Web Application Serverless microservices design with React application
that makes API calls to REST endpoints that map to Lambda functions on a cloud like AWS. The REST API returns JSON
that the UI client code injects into the React code to render the UI elements. Could use the below AWS tool chain....
Option 2: GraphQL FaaS Using React UI & Relay
Three-Tier Web Application Serverless GraphQL design that maps to a Lambda function
on a cloud like AWS. Relay facilitates the connection between React components on the client side and the data retrieved
from GraphQL services. This is a significantly simplier design pattern than Option 1: REST API Microservices FaaS.
Option 3: GraphQL FaaS Using Apollo
Three-Tier Web Application Serverless GraphQL design that maps to a Lambda function
on a cloud like AWS. This is a significantly simplier design pattern than Option 1: REST API Microservices FaaS.
Three-Tier Web Application Serverless GraphQL design that maps to a Lambda function
on a cloud like AWS. This is a significantly simplier design pattern than Option 1: REST API Microservices FaaS.
Option 5: Move Legacy REST API to AWS Using AWS API Gateway
With AWS API Gateway move a legacy microservices REST API to AWS can be
accomplished with little effort and practically no need to write any code.
Option 6: Integrate Legacy REST API into New REST API through AWS API Gateway Proxy
Integrate request and response calls on legacy microservices REST API through AWS API Gateway proxy that
also implements a completely new REST API with a new structure by configuring the AWS API Gateway and using Velocity templates.
Option 7: Event Triggered Parallel Processing in AWS FaaS
Fan-Out Design Pattern Parallel Processing in an AWS Serverless environment can be
triggered by an AWS S3 delta that fires off a Lambda function that starts multiple parallel processes. Some of the
positive effects of this design pattern are reduced latency over what is possible with a single process plus all
the benefits associated with the cloud like automatic scaling up and down without the need to maintain
any infrastructure. Many more benefits are possible but not conveyed in this short synopsis.
Option 8: Event Triggered SNS Notification on Topic Parallel Processing in AWS FaaS
SNS Fan-Out Design Pattern Parallel Processing in an AWS Serverless
environment occurs when an SNS triggers multiple subscriber topic listener Lambda function workers.
Some of the positive effects of this design pattern are reduced latency over what is possible with a single
process, the elimination of the single entry Lambda function parallel process initiator in favor of multiple
SNS subscriber Lambda worker functions, plus all the benefits associated with the cloud like automatic
scaling up and down without the need to maintain any infrastructure. Many more benefits are possible
but not conveyed in this short synopsis.
Option 9: Stream Processing System in AWS FaaS
One-to-many Lambda functions in a serverless AWS cloud can simultaneously
read and process the same messages until they expire. On AWS use AWS Kinesis NOT Apache Kafka.
Just as human bones get stronger when subjected to stress and tension, and rumors or riots intensify when someone tries to repress them,
many things in life benefit from stress, disorder, volatility, and turmoil. What Taleb has identified and calls “antifragile” is that
category of things that not only gain from chaos but need it in order to survive and flourish. In The Black Swan, Taleb showed us that
highly improbable and unpredictable events underlie almost everything about our world. In Antifragile, Taleb stands uncertainty on its head,
making it desirable, even necessary, and proposes that things be built in an antifragile manner. The antifragile is beyond the resilient
or robust. The resilient resists shocks and stays the same; the antifragile gets better and better. Furthermore, the antifragile is immune
to prediction errors and protected from adverse events. Why is the city-state better than the nation-state, why is debt bad for you, and
why is what we call “efficient” not efficient at all? Why do government responses and social policies protect the strong and hurt the weak?
Why should you write your resignation letter before even starting on the job? How did the sinking of the Titanic save lives? The book spans
innovation by trial and error, life decisions, politics, urban planning, war, personal finance, economic systems, and medicine. And throughout,
in addition to the street wisdom of Fat Tony of Brooklyn, the voices and recipes of ancient wisdom, from Roman, Greek, Semitic, and medieval
sources, are loud and clear.
All complex computer systems eventually break, despite all of the heavy-handed, bureaucratic change-management processes we throw at them.
But some systems are clearly more fragile than others, depending on how well they cope with stress. In this O’Reilly report, Dave Zwieback
explains how the DevOps methodology can help make your system antifragile. Systems are fragile when organizations are unprepared to handle
changing conditions. As generalists adept at several roles, DevOps practitioners adjust more easily to the fast pace of change. Rather than
attempt to constrain volatility, DevOps embraces disorder, randomness, and impermanence to make systems even better. Why Etsy, Netflix, and
other antifragile companies constantly introduce volatility to test and upgrade their systems How DevOps removes the schism between developers
and operations, enlisting developers to deploy as well as build Using continual experimentation and minor failures to make critical
adjustments—and discover breakthroughs How an overreliance on measurement and automation can make systems fragile Why sharing increases
trust, collaboration, and tribal knowledge Download this free report and learn how the DevOps philosophy of Culture, Automation, Measurement,
and Sharing makes use of changing conditions and even embarrassing mistakes to help improve your system—and your organization.
Learning Elastic Stack 6.0
Author: Sharath Kumar M N, Pranav Shukla
Site Reliability Engineering
Author: Jennifer Petoff, Niall Richard Murphy, Chris Jones, Betsy Beyer
Get valuable insights from your data by working with the different components of the Elastic stack such as Elasticsearch, Logstash, Kibana,
X-Pack, and Beats. The Elastic Stack is a powerful combination of tools for distributed search, analytics, logging, and visualization of
data from medium to massive data sets. The newly released Elastic Stack 6.0 brings new features and capabilities that empower users to find
unique, actionable insights through these techniques. This book will give you a fundamental understanding of what the stack is all about,
and how to use it efficiently to build powerful real-time data processing applications. After a quick overview of the newly introduced
features in Elastic Stack 6.0, you'll learn how to set up the stack by installing the tools, and see their basic configurations. Then it
shows you how to use Elasticsearch for distributed searching and analytics, along with Logstash for logging, and Kibana for data
visualization. It also demonstrates the creation of custom plugins using Kibana and Beats. You'll find out about Elastic X-Pack, a useful
extension for effective security and monitoring. We also provide useful tips on how to use the Elastic Cloud and deploy the Elastic Stack
in production environments.
The overwhelming majority of a software system’s lifespan is spent in use, not in design or implementation. So, why does conventional wisdom
insist that software engineers focus primarily on the design and development of large-scale computing systems? In this collection of essays and
articles, key members of Google’s Site Reliability Team explain how and why their commitment to the entire lifecycle has enabled the company to
successfully build, deploy, monitor, and maintain some of the largest software systems in the world. You’ll learn the principles and practices
that enable Google engineers to make systems more scalable, reliable, and efficient—lessons directly applicable to your organization.
Author: Eric Evans
Continuous Delivery and DevOps - A Quickstart Guide - Third Edition
Author: Paul Swartout
Readers learn how to use a domain model to make a complex development effort more focused and dynamic. A core of best practices and
standard patterns provides a common language for the development team. A shift in emphasis-refactoring not just the code but the model
underlying the code-in combination with the frequent iterations of Agile development leads to deeper insight into domains and enhanced
communication between domain expert and programmer. Domain-Driven Design then builds on this foundation, and addresses modeling and design
for complex systems and larger organizations.
Over the past few years, Continuous Delivery (CD) and DevOps have been in the spotlight in tech media, at conferences, and in boardrooms
alike. Many articles and books have been written covering the technical aspects of CD and DevOps, yet the vast majority of the industry
doesn’t fully understand what they actually are and how, if adopted correctly they can help organizations drastically change the way they
deliver value. This book will help you figure out how CD and DevOps can help you to optimize, streamline, and improve the way you work to
consistently deliver quality software. In this edition, you’ll be introduced to modern tools, techniques, and examples to help you understand
what the adoption of CD and DevOps entails. It provides clear and concise insights in to what CD and DevOps are all about, how to go about
both preparing for and adopting them, and what quantifiable value they bring. You will be guided through the various stages of adoption, the
impact they will have on your business and those working within it, how to overcome common problems, and what to do once CD and DevOps have
become truly embedded. Included within this book are some real-world examples, tricks, and tips that will help ease the adoption process and
allow you to fully utilize the power of CD and DevOps.
Author: Susan J. Fowler
Designing Data-Intensive Applications
Author: Martin Kleppmann
One of the biggest challenges for organizations that have adopted microservice architecture is the lack of architectural, operational,
and organizational standardization. After splitting a monolithic application or building a microservice ecosystem from scratch, many
engineers are left wondering what’s next. In this practical book, author Susan Fowler presents a set of microservice standards in depth,
drawing from her experience standardizing over a thousand microservices at Uber. You’ll learn how to design microservices that are stable,
reliable, scalable, fault tolerant, performant, monitored, documented, and prepared for any catastrophe.
Data is at the center of many challenges in system design today. Difficult issues need to be figured out, such as scalability,
consistency, reliability, efficiency, and maintainability. In addition, we have an overwhelming variety of tools, including relational
databases, NoSQL datastores, stream or batch processors, and message brokers. What are the right choices for your application? How do
you make sense of all these buzzwords? In this practical and comprehensive guide, author Martin Kleppmann helps you navigate this diverse
landscape by examining the pros and cons of various technologies for processing and storing data. Software keeps changing, but the
fundamental principles remain the same. With this book, software engineers and architects will learn how to apply those ideas in practice, and
how to make full use of data in modern applications.
Artificial Intelligence - Foundations of Computational Agents
Author: David L. Poole; Alan K. Mackworth
Elasticsearch: The Definitive Guide
Author: Clinton Gormley, Zachary Tong
Artificial intelligence, including machine learning, has emerged as a transformational science and engineering
discipline. Artificial Intelligence: Foundations of Computational Agents presents AI using a coherent framework to
study the design of intelligent computational agents. By showing how the basic approaches fit into a multidimensional
design space, readers learn the fundamentals without losing sight of the bigger picture. The new edition also features
expanded coverage on machine learning material, as well as on the social and ethical consequences of AI and ML. The
book balances theory and experiment, showing how to link them together, and develops the science of AI together with
its engineering applications. Although structured as an undergraduate and graduate textbook, the book's straightforward,
self-contained style will also appeal to an audience of professionals, researchers, and independent learners. The second
edition is well-supported by strong pedagogical features and online resources to enhance student comprehension.
Whether you need full-text search or real-time analytics of structured data—or both—the Elasticsearch distributed search engine
is an ideal way to put your data to work. This practical guide not only shows you how to search, analyze, and explore data with
Elasticsearch, but also helps you deal with the complexities of human language, geolocation, and relationships. If you’re a
newcomer to both search and distributed systems, you’ll quickly learn how to integrate Elasticsearch into your application. More
experienced users will pick up lots of advanced techniques. Throughout the book, you’ll follow a problem-based approach to learn
why, when, and how to use Elasticsearch features.
Kubernetes: Up and Running
Author: Brendan Burns, Kelsey Hightower, Joe Beda
Agile Project Management With Scrum
Author: Ken Schwaber
Legend has it that Google deploys over two billion application containers a week. How’s that possible? Google revealed
the secret through a project called Kubernetes, an open source cluster orchestrator (based on its internal Borg system)
that radically simplifies the task of building, deploying, and maintaining scalable distributed systems in the cloud. This
practical guide shows you how Kubernetes and container technology can help you achieve new levels of velocity, agility,
reliability, and efficiency. Authors Kelsey Hightower, Brendan Burns, and Joe Beda—who’ve worked on Kubernetes at Google
and other organizatons—explain how this system fits into the lifecycle of a distributed application. You will learn how
to use tools and APIs to automate scalable distributed systems, whether it is for online services, machine-learning
applications, or a cluster of Raspberry Pi computers.
The rules and practices for Scrum-a simple process for managing complex projects-are few, straightforward, and
easy to learn. But Scrum's simplicity itself-its lack of prescription-can be disarming, and new practitioners often
find themselves reverting to old project management habits and tools and yielding lesser results. In this illuminating
series of case studies, Scrum co-creator and evangelist Ken Schwaber identifies the real-world lessons—the successes
and failures—culled from his years of experience coaching companies in agile project management. Through them, you'll
understand how to use Scrum to solve complex problems and drive better results-delivering more valuable software faster.
User Stories Applied
Author: Mike Cohn
The Enterprise Path to Service Mesh Architectures
Author: Lee Calcote
Thoroughly reviewed and eagerly anticipated by the agile community, User Stories Applied offers a requirements process
that saves time, eliminates rework, and leads directly to better software. The best way to build software that meets users'
needs is to begin with "user stories": simple, clear, brief descriptions of functionality that will be valuable to real users.
In User Stories Applied, Mike Cohn provides you with a front-to-back blueprint for writing these user stories and weaving them
into your development lifecycle. You'll learn what makes a great user story, and what makes a bad one. You'll discover practical
ways to gather user stories, even when you can't speak with your users. Then, once you've compiled your user stories, Cohn shows
how to organize them, prioritize them, and use them for planning, management, and testing.
This free, complete, O’Reilly ebook shows how service meshes work & provides a path to help you build or convert applications. It
explains how a service mesh provides a configurable infrastructure layer that makes service-to-service communication flexible, reliable,
and fast. Whether you’re preparing to build microservice-architected, cloud-native applications or looking to modernize your existing
set of application services, you may want to consider using a service mesh. The more services your enterprise manages, the more intense
your headaches are likely to be. This practical ebook explains how a service mesh provides a configurable infrastructure layer that makes
service-to-service communication flexible, reliable, and fast. Author Lee Calcote, Head of Technology Strategy at SolarWinds, demonstrates
how service meshes work and provides a path to help you build or convert applications using this architecture. This ebook is ideal for
developers, operators, architects, and IT leaders tasked with building distributed systems. You’ll learn how service meshes function with
other technologies in your stack as well as how to overcome issues that may arise.
AWS Certified Solutions Architect - Official Study Guide
Author: Joe Baron, Hisham Baz, Tim Bixler, Biff Gaut, Kevin E. Kelly, Sean Senior, John Stamper
Building Evolutionary Architectures
Author: Neal Ford, Rebecca Parsons, Patrick Kua ffffffffffffffffffffffffffffffff
This is your opportunity to take the next step in your career by expanding and validating your skills on the AWS cloud.
AWS has been the frontrunner in cloud computing products and services, and the AWS Certified Solutions Architect Official
Study Guide for the Associate exam will get you fully prepared through expert content, and real-world knowledge, key exam
essentials, chapter review questions, access to Sybex's interactive online learning environment, and much more.
The software development ecosystem is constantly changing, providing a constant stream of new tools, frameworks, techniques,
and paradigms. Over the past few years, incremental developments in core engineering practices for software development have
created the foundations for rethinking how architecture changes over time, along with ways to protect important architectural
characteristics as it evolves. This practical guide ties those parts together with a new way to think about architecture and time.
Author: Sam Newman
Release It: Design and Deploy Production-Ready Software
Author: Michael Nygard
Distributed systems have become more fine-grained in the past 10 years, shifting from code-heavy monolithic applications to
smaller, self-contained microservices. But developing these systems brings its own set of headaches. With lots of examples and
practical advice, this book takes a holistic view of the topics that system architects and administrators must consider when
building, managing, and evolving microservice architectures.
A single dramatic software failure can cost a company millions of dollars—but can be avoided with simple changes to design and
architecture. This new edition of the best-selling industry standard shows you how to create systems that run longer, with fewer
failures, and recover better when bad things happen. New coverage includes DevOps, microservices, and cloud-native architecture.
Stability antipatterns have grown to include systemic problems in large-scale systems. This is a must-have pragmatic guide to
engineering for production systems.
Restful Web Services
Author: Leonard Richardson, Sam Ruby
Rest In Practice: Hypermedia and Systems Architecture
Author: Savas Parastatidis, Jim Webber, Ian Robinson
You've built web sites that can be used by humans. But can you also build web sites that are usable by machines? That's
where the future lies, and that's what RESTful Web Services shows you how to do. The World Wide Web is the most popular
distributed application in history, and Web services and mashups have turned it into a powerful distributed computing platform.
But today's web service technologies have lost sight of the simplicity that made the Web successful. They don't work like the Web,
and they're missing out on its advantages.
Why don't typical enterprise projects go as smoothly as projects you develop for the Web? Does the REST architectural style
really present a viable alternative for building distributed systems and enterprise-class applications? In this insightful book,
three SOA experts provide a down-to-earth explanation of REST and demonstrate how you can develop simple and elegant distributed
hypermedia systems by applying the Web's guiding principles to common enterprise computing problems. You'll learn techniques for
implementing specific Web technologies and patterns to solve the needs of a typical company as it grows from modest beginnings to
become a global enterprise.
Node.js Web Development - Fourth Edition
Author: David Herron
Java WebSocket Programming
Author: Danny Coward
Create real-time applications using Node.js 10, Docker, MySQL, MongoDB, and Socket.IO with this practical guide and go beyond the
an event-driven, non-blocking I/O model allowing users to build fast and scalable data-intensive applications running in real time. This
book gives you an excellent starting point, bringing you straight to the heart of developing web applications with Node.js. You will
own Node.js application.You will understand the importance of transitioning to functions that return Promise objects, and the difference
between fs, fs/promises and fs-extra. With this book you'll learn how to use the HTTP Server and Client objects, data storage with both
SQL and MongoDB databases, real-time applications with Socket.IO, mobile-first theming with Bootstrap, microservice deployment with Docker,
authenticating against third-party services using OAuth, and use some well known tools to beef up security of Express 4.16 applications.
Build dynamic enterprise Web applications that fully leverage state-of-the-art communication technologies. Written by the leading
expert on Java WebSocket programming, this Oracle Press guide offers practical development strategies and detailed example applications.
Java WebSocket Programming explains how to design client/server applications, incorporate full-duplex messaging, establish connections,
create endpoints, handle path mapping, and secure data. You’ll also learn how to encrypt Web transmissions and enrich legacy applications
with Java WebSocket.
Rust Quick Start Guide
Author: Daniel Arbuckle
Kong: Becoming a King of API Gateways
Author: Alex Kovalevych, Robert Buchanan, Daniel Lee, Chelsy Mooy, Xavier Bruhiere & Jose Ramon Huerga
Rust is an emerging programming language applicable to areas such as embedded programming, network programming, system programming, and
web development. This book will take you from the basics of Rust to a point where your code compiles and does what you intend it to do!
This book starts with an introduction to Rust and how to get set for programming, including the rustup and cargo tools for managing a
Rust installation and development workﬂow. Then you'll learn about the fundamentals of structuring a Rust program, such as functions,
mutability, data structures, implementing behavior for types, and many more. You will also learn about concepts that Rust handles
differently from most other languages. After understanding the Basics of Rust programming, you will learn about the core ideas, such
as variable ownership, scope, lifetime, and borrowing. After these key ideas, you will explore making decisions in Rust based on data
types by learning about match and if let expressions. After that, you'll work with different data types in Rust, and learn about memory
management and smart pointers.
An API Gateway is an essential component in microservice architecture. This book is useful for IT architects, DevOps engineers, CTOs
and security experts willing to understand how to use Kong to create and expose APIs. Even if you are not already familiar with Kong,
it will only take a few minutes to create your first API. Are you an architect interested in understanding how an API Gateway can simplify
and improve security of a micorservices architecture? Are you a developer interested in knowing what you can do with Kong plugins, and
how you can extend Kong with custom Lua plugins? Or are you an Ops / Sysadmin needing to know how to operate Kong in a multi-region
environment? This book addresses these needs and more. Use an API gateway to simplify and improve the security of your microservices
architecture. Write Kong plugins with Lua. Deploy Kong and Cassandra in a multi-region environment. Use load balancing features.
Cassandra: The Definitive Guide, 2nd Edition
Author: Eben Hewitt, Jeff Carpenter
Inviting Disaster: Lessons From the Edge of Technology
Author: James R. Chiles
Imagine what you could do if scalability wasn't a problem. With this hands-on guide, you’ll learn how the Cassandra database management
system handles hundreds of terabytes of data while remaining highly available across multiple data centers. This expanded second
edition—updated for Cassandra 3.0—provides the technical details and practical examples you need to put this database to work in a
production environment. Authors Jeff Carpenter and Eben Hewitt demonstrate the advantages of Cassandra’s non-relational design, with
special attention to data modeling. If you’re a developer, DBA, or application architect looking to solve a database scaling issue or
future-proof your application, this guide helps you harness Cassandra’s speed and flexibility.
Combining captivating storytelling with eye-opening findings, Inviting Disaster delves inside some of history's worst catastrophes in order to
show how increasingly "smart" systems leave us wide open to human tragedy.Weaving a dramatic narrative that explains how breakdowns in these
systems result in such disasters as the chain reaction crash of the Air France Concorde to the meltdown at the Chernobyl Nuclear Power Station,
Chiles vividly demonstrates how the battle between man and machine may be escalating beyond manageable limits -- and why we all have a stake in
Author: Mike Amundsen, Matt McLarty, Ronnie Mitra, Irakli Nadareishvili
Lua Quick Start Guide
Author: Gabor Szauer
Have you heard about the tremendous success Amazon and Netflix have had by switching to a microservice architecture? Are you wondering
how this can benefit your company? Or are you skeptical about how it might work? If you’ve answered yes to any of these questions, this
practical book will benefit you. You'll learn how to take advantage of the microservice architectural style for building systems, and
learn from the experiences of others to adopt and execute this approach most successfully.
Lua is a small, powerful and extendable scripting/programming language that can be used for learning to program, and writing games
and applications, or as an embedded scripting language. There are many popular commercial projects that allow you to modify or extend
them through Lua scripting, and this book will get you ready for that. This book is the easiest way to learn Lua. It introduces you to
the basics of Lua and helps you to understand the problems it solves. You will work with the basic language features, the libraries Lua
provides, and powerful topics such as object-oriented programming. Every aspect of programming in Lua, variables, data types, functions,
tables, arrays and objects, is covered in sufficient detail for you to get started. You will also find out about Lua's module system and
how to interface with the operating system.
Continuous API Management
Author: Mike Amundsen, Ronnie Mitra, Mehdi Medjaoui, Erik Wilde
Docker: Up & Running
Author: Karl Matthias, Sean Kane
A lot of work is required to release an API, but the effort doesn’t always pay off. Overplanning before an API matures is a wasted investment,
while underplanning can lead to disaster. This practical guide provides maturity models for individual APIs and multi-API landscapes to help
you invest the right human and company resources for the right maturity level at the right time. How do you balance the desire for agility and
speed with the need for robust and scalable operations? Four experts from the API Academy show software architects, program directors, and
product owners how to maximize the value of their APIs by managing them as products through a continuous life cycle.
Docker is quickly changing the way that organizations are deploying software at scale. But understanding how Linux containers fit into your
workflow—and getting the integration details right—are not trivial tasks. With this practical guide, you’ll learn how to use Docker to package
your applications with all of their dependencies, and then test, ship, scale, and support your containers in production. Two Lead Site
Reliability Engineers at New Relic share much of what they have learned from using Docker in production since shortly after its initial
release. Their goal is to help you reap the benefits of this technology while avoiding the many setbacks they experienced.
Arduino Robotic Projects
Author: Richard Grimmett
Author: Andrea Chiarelli
This book is for anyone who has been curious about using Arduino to create robotic projects that were previously the domain of research
labs of major universities or defense departments. Some programming background is useful, but if you know how to use a PC, you can, with
the aid of the step-by-step instructions in this book, construct complex robotic projects that can roll, walk, swim, or fly. Arduino is
an open source microcontroller, built on a single circuit board that is capable of receiving sensory input from the environment and
controlling interactive physical objects. Arduino Robotic Projects starts with the fundamentals of turning on the basic hardware and
then provides complete, step-by-step instructions that allow almost anyone to use this low-cost hardware platform. You'll build projects
that can move using DC motors, walk using servo motors, and then add sensors to avoid barriers. You'll also learn how to add more complex
navigational techniques such as GPRS so that your robot won't get lost.
Projects like Angular and React are rapidly changing how development teams build and deploy web applications to production. In this book,
you’ll learn the basics you need to get up and running with React and tackle real-world projects and challenges. It includes helpful guidance
on how to consider key user requirements within the development process, and also shows you how to work with advanced concepts such as state
management, data-binding, routing, and the popular component markup that is JSX. As you complete the included examples, you’ll find yourself
well-equipped to move onto a real-world personal or professional frontend project.
Serverless Design Patterns and Best Practices
Author: Brian Zambrano
Author: Alex Banks, Eve Porcello
Serverless applications handle many problems that developers face when running systems and servers. The serverless pay-per-invocation
model can also result in drastic cost savings, contributing to its popularity. While it's simple to create a basic serverless application,
it's critical to structure your software correctly to ensure it continues to succeed as it grows. Serverless Design Patterns and Best
Practices presents patterns that can be adapted to run in a serverless environment. You will learn how to develop applications that are
scalable, fault tolerant, and well-tested. The book begins with an introduction to the different design pattern categories available for
serverless applications. You will learn the trade-offs between GraphQL and REST and how they fare regarding overall application design in
a serverless ecosystem. The book will also show you how to migrate an existing API to a serverless backend using AWS API Gateway. You will
learn how to build event-driven applications using queuing and streaming systems, such as AWS Simple Queuing Service (SQS) and AWS Kinesis.
Patterns for data-intensive serverless application are also explained, including the lambda architecture and MapReduce.
Why is GraphQL the most innovative technology for fetching data since Ajax? By providing a query language for your APIs and a runtime for
fulfilling queries with your data, GraphQL presents a clear alternative to REST and ad hoc web service architectures. With this practical
guide, Alex Banks and Eve Porcello deliver a clear learning path for frontend web developers, backend engineers, and project and product
managers looking to get started with GraphQL. You’ll explore graph theory, the graph data structure, and GraphQL types before learning
hands-on how to build a schema for a photo-sharing application. This book also introduces you to Apollo Client, a popular framework you
can use to connect GraphQL to your user interface.
Author: Jez Humble, David Farley
The Challenger Launch Decision: Risky Technology, Culture, and Deviance at NASA
Author: Diane Vaughan
Getting software released to users is often a painful, risky, and time-consuming process. This
groundbreaking new book sets out the principles and technical practices that enable
rapid, incremental delivery of high quality, valuable new functionality to users. Through
automation of the build, deployment, and testing process, and improved collaboration between
developers, testers, and operations, delivery teams can get changes released in a matter of hours—
sometimes even minutes–no matter what the size of a project or the complexity of its code base.
Jez Humble and David Farley begin by presenting the foundations of a rapid, reliable, low-risk
delivery process. Next, they introduce the “deployment pipeline,” an automated process for
managing all changes, from check-in to release. Finally, they discuss the “ecosystem” needed to
support continuous delivery, from infrastructure, data and configuration management to governance.
The authors introduce state-of-the-art techniques, including automated infrastructure management
and data migration, and the use of virtualization. For each, they review key issues, identify best
practices, and demonstrate how to mitigate risks.
When the Space Shuttle Challenger exploded on January 28, 1986, millions of Americans became bound
together in a single, historic moment. Many still vividly remember exactly where they were and what
they were doing when they heard about the tragedy. Diane Vaughan recreates the steps leading up to
that fateful decision, contradicting conventional interpretations to prove that what occurred at
NASA was not skullduggery or misconduct but a disastrous mistake. Why did NASA managers, who not only
had all the information prior to the launch but also were warned against it, decide to proceed? In
retelling how the decision unfolded through the eyes of the managers and the engineers, Vaughan uncovers
an incremental descent into poor judgment, supported by a culture of high-risk technology. She reveals
how and why NASA insiders, when repeatedly faced with evidence that something was wrong, normalized the
deviance so that it became acceptable to them. In a new preface, Vaughan reveals the ramifications for
this book and for her when a similar decision-making process brought down NASA's Space Shuttle Columbia
TCP/IP Sockets In Java
Author: Kenneth Calvert Michael Donahoo
Lean Software Development: An Agile Toolkit
Author: Mary Poppendieck, Tom Poppendieck
The API (application programming interface) reference sections in each chapter, which describe the relevant parts of each class,
have been replaced with (i) a summary section that lists the classes and methods used in the code, and (ii) a "gotchas" section
that mentions nonobvious or poorly-documented aspects of the objects. In addition, the book covers several new classes and
capabilities introduced in the last few revisions of the Java platform. New abstractions to be covered include NetworkInterface,
InterfaceAddress, Inet4/6Address, SocketAddress/InetSocketAddress, Executor, and others; extended access to low-level network
information; support for IPv6; more complete access to socket options; and scalable I/O. The example code is also modified to
take advantage of new language features such as annotations, enumerations, as well as generics and implicit iterators where
In Lean Software Development, Mary and Tom Poppendieck identify seven fundamental "lean" principles, adapt them for the world
of software development, and show how they can serve as the foundation for agile development approaches that work. Along the way,
they introduce 22 "thinking tools" that can help you customize the right agile practices for any environment. Better, cheaper,
faster software development. You can have all three–if you adopt the same lean principles that have already revolutionized
manufacturing, logistics and product development.
A Concise Guide to Microservices for Executive (Now for DevOps too!)
Author: Alasdair Gilchrist
Learn to Program with C++ - First Edition
Author: John Smiley
Organizations that have successfully laid a foundation for continuous innovation and agility have adopted microservice architectures
to respond rapidly to the demands of their business. Microservices are the evolution of best-practice architectural principles that
shape the delivery of solutions to the business in the form of services. All businesses, no matter what industry they are in, must
strive to deliver the ideal customer experience, as customers are more demanding than ever and will abandon a business that is too
slow to respond. A microservice architecture aligns with the business in such a way that changes to your business can be dealt with
in an agile fashion. The ease and speed with which your company can change will determine your ability to react to trends in your
industry to remain competitive. In this updated 2nd edition we take a high-level approach to describing the microservice architecture
and how that aligns with the organisation's business goals. We describe the microservice patterns, and the pros and cons of when and
where they should be deployed, which provide you with a good overall education in this new development paradigm. However, in this
updated edition we go much further, as we take a deeper dive into microservice design, implementation and the nuances of networking
and monitoring. We discuss preferred infrastructure models and connectivity protocols as well as contemplate several use-cases for
microservices such as micro-front-ends, the IoT and GDPR. Finally, we close with an extensive summary of the main takeaways from this
the 2nd edition of 'A concise guide to Microservices for Executives - and now DevOps too!'
Join Professor Smiley's C++ class as he teaches essential skills in programming, coding, and more. Using a student-instructor
conversational format, this book starts at the very beginning with crucial programming fundamentals. You'll quickly learn how to
identify customer needs so that you can create an application that achieves programming objectives--just like experienced programmers.
By identifying clear client goals, you'll learn important programming basics--like how computers view input and execute output based on
the information they are given--then use those skills to develop real-world applications. Participate in this one-of-a-kind classroom
experience and see why Professor Smiley is renowned for making learning fun and easy.
Learn fundamental programming concepts, which can be applied to multiple languages
Develop your C++ skills with real-world, hands-on programming projects
Work with program variables, constants, and C++ data types
Create and run a C++ program using Windows Notepad
Adapt to runtime conditions with selection structures and statements
Use loops to increase your programming power
Learn about pointers, arrays, objects, classes, and more
Restlet in Action - Developing RESTful web APIs in Java
Authors: Jerome Louvel, Thierry Templier, and Thierry Boileau
Restlet in Action gets you started with the Restlet Framework and the REST architecture style. You'll create and
deploy applications in record time while learning to use popular RESTful Web APIs effectively. This book looks at
the many aspects of web development, on both the server and client side, along with cloud computing, mobile Android
devices, and Semantic Web applications.
"The number of errors in code correlates strongly with the amount of code and the complexity of the code."
- Bjarne Stroustrup A Tour of C++, 2nd edition
Author: Ray Pairan Jr.
Natural ecosystems like the biosphere are sophisticated interconnected complex dynamic systems where slight changes in any of
the member elements can ripple across the whole organized chaotic sub-structures precipitating a series of uncontrolled and
typically unknown events. Balance in natural systems is achieved over eons of transmutations and shorter term transitions moving
towards symbiotic sustainable state changes that tend to keep the entire ecosystem stable. Complex technical systems, those that
human beings design are replicas of the natural ecosystems we come in contact with daily. These numerous sub-system marvels with
layers of open-source abstractions and thousands of service and micro-service interfaces have the same vulnerabilities that plague
all complex dynamic systems; system destabilization triggered by sub-system singularity deviations from expected behavior sets.
There is always the danger when adding layers of abstraction to systems that we will create overly complex dynamic systems of
the same brittleness as natural systems. Every interface or connection point is a weak link in a chain of relative complexity. A
network, either natural (like the air, ocean, lithosphere, or biosphere) or human (like the Internet) can amplify an errant
elemental sub-system connection or interface instability throughout an entire system superstructure.
Well designed complex technical systems where the bulkhead design pattern has been implemented can inhibit errors in sub-systems
from rippling across and destabilizing the larger system by limiting the divergence of the entire system from its normal complex
dynamic system homeostasis state. Another way to reduce undesirable system superstructure aberrations outside normal operating
parameters is to build systems that have fewer layers of abstraction, limited complexity, and less interconnected dependencies.
Steps should always be taken to actively reduce complexity, the layers of abstractions, and the number of dependencies across
all elements of a system superstructure. Technologists have the responsibility to embrace a mindset of constant simplification of
the system architecture and code-base - for complexity begets instability – the bizarre destabilized disturbances that travel
Not included in the below synopsis of AWS database features is an elaboration on Amazon Redshift or Amazon DynamoDB.
Primary Instance: Is the main instance supporting both read and write workloads. When
modifying data, the change occurs on the primary instance. Each Amazon Aurora DB cluster has one primary instance.
RDBMS – Amazon Relational Database (RDS)
NOSQL – Amazon DynamoDB
Warehouse – Amazon Redshift
Any database engine can be run within Amazon EC2 instances, but you must handle the installation and administration
Amazon RDS Oracle and Microsoft SQL Server are their own unique products that require appropriate licenses to operate
in AWS. Bringing over your own Enterprise Edition or other license to AWS is acceptable.
Supports six RDBMS database engines: Oracle, Amazon Aurora, PostgreSQL, MS SQL Server, MariaDB, MySQL Server
After successfully restoring my Linux Ubuntu 14.04 LTS OS in one of my partitions of my dual boot configured laptop and during this process needing
to get a connection via the command line below are my vetted steps to link to a WPA2 WIFI network.
Make certain you are in Root and you know the name of your interface. On personal computers it is typically wlan0.
Turn on wireless card
$ifconfig wlan0 up
Turn on interface
$ip link set wlan0 up
Scan for wireless networks and locate the network's SSID you want to connect to and ensure that it is up
$iw wlan0 scan | less
Create wpa-supplicant.conf file with password for the SSID.
NOTE: If you have already created this config file just skip this step
$wpa_passphrase 'Name of WIFI network/hotspot' 'Password for WIFI network/hotspot' > /etc/wpa_supplicant.conf
Display the wpa_supplicant.conf file to verify the name and password are correct
Connect to WIFI network/hotspot
NOTE: The default driver is n180211 so there is no need to specify the driver.
If the connection fails you will need to determine what driver you should be using but first try
wext which is an all-purpose driver such that the new command is:
$wpa_supplicant -B -i wlan0 -c /etc/wpa_supplicant.conf -D wext
The above is a description of the basics to connect to a WPA2 WIFI network using the Linux Ubuntu command line. Obviously, there
are many verification steps that have been omitted to keep this step-by-step process succinct.
Tools like Bamboo are used for release
automation (auto-deploy) to move builds from environments like development, QA, and finally to production in Blue pre-delta PROD or Green
post-delta PROD. The entire continuous integration process needs to be fused together in a coherent and logical sequence of events utilizing
Separate the build and run stages such that there are well defined build, release, and run processes. Keep DEV, staging,
and PROD as similar as possible to ensure DEV/PROD parity.
In conjunction with utilizing release automation tools the entire continuous integration process also uses source control tools like SVN or
Git/GitBucket with Sonar, Blackduck, and possibly Vericode to check the code throughout the integration phases for code quality standards and
security requirements adherence.
Artifactory should also be integrated into the continuous integration process to ensure that only pre-authorized open-source and non-open source
code libraries and other dependencies are pulled to DEV and utilized during the development phase across iterations.
Most QA testing including Fuzz-Testing should be automated in the continuous integration process build pipeline. Also, running outbound generative
tests against service dependencies of an application making them act the way you expect can also ensure that anomalies with micro-services are
isolated in the build pipeline instead of when the system is migrated to PROD.
Suffice to say, looking only at the end state PROD ON or PROD OFF deployment in a release process is probably an anti-pattern in the creation of
production ready software. Unfortunately, the entire macro continuous integration process must be analyzed when even just moving to an end state
PROD strategy like BLUE/GREEN.
Architectural requirements can even be incorporated into a continuous integration process to ensure the architectural fitness of the system. Tools like
JDepend and NDepend exist to test the architectural fitness of an application during the build process. Rules defined to protect the architectural
dimensions execute each time the system changes.
The end goal is to optimize our systems for a hostile and turbulent world instead of an idealized
environment. Architect and design-in failure modes that will protect the most critical parts of the application because with certainty all software
fails some more adversely than others. Systems with many integration points across multiple dependencies, those that are highly complex, tightly
coupled, and without failure bulkheads to prevent breakdown propogation have a higher probability of failure than lean, minimalist, loosely-coupled,
and less-complex applications. Each dependency or needless complexity that a system has raises the risk for a cascading failure. So just because
you have an out-of-sight and out-of-mind usecase philosophy when utilizing opensource and non-opensource libraries does not mean reality will
not strike, bringing your system to it's knees.
Just read an article on “The Guardian” entitled:
Franken-algorithms: the deadly consequences of unpredictable code,
that among other interesting insights pretty much agrees with my theory that we
should write lean, predictable, and understandable code that we can generally ensure expected outcomes that are the ones our customers and stakeholders
Layer upon layer of libraries and open-source code that has not been fully vetted for code quality to generally accepted standards and most certainly
has not been tested to the extent that we would test project code at the highest layer of abstraction for our customers could be a source of unacceptable
uncertainty with potential negative consequences
At what point in layers of abstraction does an application become brittle and tightly coupled to code we may not have any control over?
None of what I am inferring suggests that we should throw out open-source especially since this egalitarian form
of software development embraces the best in humankind’s desire to build resilient communities based on cooperation. Only that we should be very
careful in how many layers we pile on-top of what may potentially become ‘spaghetti-code” that is so convoluted it’s state transitions and ending states
Just wanted to share the article because far too often when we are flying at warp speed through projects it is easy to lose sight of some of the basic
tenets of software engineering.
There is nothing de facto requiring that all RESTful services use JSON to transfer data. Furthermore, JSON requires that the application a
priori understand the data structure and semantics prior to parsing a JSON document. Once again, the technology community has thrown out a
perfectly good technology, labeled this technology deficient (in the case of XML - verbose), and had those who were ill-informed about the
entire capabilities of the technology drive the purging of this new technology heresy.
First we throw out DTDs that were a very simple way of describing an XML document to an external system. Then the technology community decided
that the overly complex XML Schema XSDs would better describe an XML document to an external application. In the process those of us in the
forefront of developing the XML standards back in the late 1990’s just scratched our heads in wonder at how a very simple and complete technology
could be so convoluted by those who knew so little about the underpinning of this document structure.
Go back to the basics using a simple but complete DTD XML document definition (that is if you can find a parser able to parse this definition)
otherwise just use an XSD bare bones. You do not need to pollute the application layer with code that needs to comprehend the definitional
characteristics of a document like JSON. An XML DTD or XSD can already do this admirably. In fact, DTDs and XSDs for different XML document type
payloads can be agreed upon across an industry or within any organizational structure – branch your code to handle any document types you need
to be made aware of for the application processes. When you receive a valid document that conforms to the DTD or XSD your code can use the many
abstraction layers for parsing that already exist in various languages to parse the document of a specified type. If you are a fan of object
oriented languages create a single Abstract class with method signatures and method implementations and sub-class from this abstraction for the
various type of documents you need to build in your document library. Much, much more can be done that has been lost over time that needs to be
Furthermore, there is all this talk of how we need to pass semantics across the wire to various disparate systems to build a firmer AI substrate.
Once again, those leading the charge to toss out XML never really understood it in the first place. XML attributes (now very rarely ever discussed –
mostly forgotten) were always intended to carry the semantic meaning of each node across the parent child relationship to create a semantic map of
the entire structure.
So before we get on the bandwagon to ride the next bright and flashy shinning trinket into oblivion we should first more fully understand the
technology we are trying to supplant.
This document presents an implementation strategy for Hypermedia as the Engine of Application State (HATEOAS). It addresses the alignment with HATEOAS,
a Micro-Service architecture, and follows bounded context/service domains.
Link relations expose application transition states
Links advertise legitimate application state transitions
On each iteration, the service and consumer exchange representations of resource state, not application state
Retrieving info via GET provides resource state representation
Change web application state via POST
Are there any benefits in using WebSockets that create a TCP connection to stream data?
Are we able to monitor and track service processes across context boundaries?
How does caching affect the successful implementation of HATEOAS web services?
Does this mean that a HATEOAS web service design pattern will always be…?
Cache-Control headers could be added by the server prior to sending the response to the client.
Servers can enforce fresh state transitions that get sent by responses to the client by eliminating
caching for a select few responses that get passed back to clients that need to know the current
Weak consistency is an inherent feature of the web due to its stateless design so maintaining state
in a distributed application that is loosely tied web services that coalesce to exhibit behaviors of a
cohesive system is challenging.
Avoid database integration at all costs … dependencies between the web service API and underlying data sources should be minimized
The purpose of REST should be to model entities
Prefer choreography over orchestration
UIs viewed more as compositionally layered
Services should be highly cohesive and loosely coupled
Keep middleware dumb and end-points smart
Services should cleanly align to bounded contexts
Service implementation should relate to resource life cycles NOT the application protocol life cycle
Keep services and micro-services technology-agnostic
Use hypermedia that conveys both business data and the information necessary to drive a protocol specific to the business domain
Use hypermedia to model state transitions and describe business protocols
Always return from the server in the response the current state of the resource like...
Synchronize state using ETag number in subsequent conditional requests to prevent race conditions
Use If-Match (in header) or If-None-Match (in header) --Conditional Request Headers
Minimize Performance Web Service Antipatterns like: Chatty I/O and Extraneous Fetching
Decouple, decouple, decouple...
When possible keep resource URIs no more complex than /collection/item/collection
Use standard web service patterns for POST, GET, PUT, and DELETE
Long running processes should use an asynchronous process that can be polled using a GET request to
the endpoint to know when the process has completed.
State Maintenance and Transitioning
Maintaining state across web service transitions may not be necessary, we may just want to provide clients with all the
relevant web service links that they can analyze for next step or interesting web services that they would like to utilize.
Workflows or process flows are mapped via web service resource calls
Process/Workflows are choreographed
Each web service resource activity/process is aware of next step or relevantly interesting web service calls given
the current state of the resources.
Advertising the next steps/processes in the protocol are accomplished by embedding hypermedia controls sent back to clients.
Server-side activities/actions/triggers that initiate a state transition are advertised through link relations
Based upon what is returned from the server the client can make informed decisions on the next course of action(s).
In some cases, the client discovers what the next course of action should be based upon its historical progression through
the application and its desired foreseeable state changes that relate to perceived positive outcomes
Suggested patterns/paths of client usage may be conveyed by the server response but the client is free to take the trail
less traveled in a quest of discovery.
State transitions via called web services dynamically evolve the transitional state changes and their resulting final
application state after user interaction has ended.
Actions/triggers are choreographed to the client along with the current application state
Even more helpful in helping the client ascertain what state transition trigger to execute would be to include the
resulting state of a web service link selection
Each web service should have its own Continuous Integration (CI) build process
Use blue/green deployment having only a single web service operational the other newly deployed instance is tested in situ.
Version control all configuration processes
Across each web service CI build pipeline: Build, Unit Tests, and Service Tests all pipelines resolve to an End-to-End set of tests.
Anytime code is checked into source control for any web service the automated build is triggered and the across web service CI pipelines
are activated just before the End-to-End tests.
Run the End-to-End tests periodically but not at the same frequency as each code change CI pipeline activation.
Make certain that each test is deterministic – resulting in behavior consistent with expectations.
Only test what needs to be tested
Using blue/green deployment test any newly deployed web service in situ – once successfully tested the newly deployed web service
replaces the running web service as the new production version.
Test to ensure that non-functional requirements are being met: acceptable latency of web pages, the number of users the system needs
to support, and other subsidiary requirements with a focus on the impact of new web services.
Across web service system level testing also needs to be done in conjunction with standard and non-functional testing.
Use the currently deployed production system as the baseline to compare your performance and non-functional requirements against
for both the aggregate web services and any newly created web services.
Use Graphite for system and
individual web service level metrics collection
Varnish will expose
other useful metrics like cache hit rates and response times.
Across web service system historical data is crucial in determining if a system is misbehaving – operating at less than optimal
specifications derived from a long-running analysis.
Call-chain monitoring in logs can be handled across web service and system boundaries by using correlation IDs in the headers.
Scaling and Limiting & Handling Failure
Up and down on demand scaling accomplished in the Cloud using infrastructure-as-a-service (IaaS)
Distribute web services across AWS availability zones (AZs) – inside each region (sub-cloud)
Implement bulkheads with Hystrix to
refuse requests under conditions of extreme saturation of resource (load shredding) so resources
do not get saturated to the point of overwhelming the entire system.
Distribute web services across AWS availability zones (AZs) – inside each region (sub-cloud)
Attempt to isolate web services so they are not dependent upon other web services.
Run several instances of each web service behind a load balancer
Do not invest time in dealing with scale that may never transpire – this is wasted effort and time best utilized elsewhere.
Copy the data in a database used by web services from the primary node to other node replicas.
Increased database write volumes can be handled by sharding.
Mongo and Cassandra offer new scaling models
Depending upon load, data freshness needs, and the responsiveness of the overall distributed web service based system opting to
have various types of caching may be desired.
The end of Java is not near, especially for the polyglot. You want to use JSF extended by Primefaces, Richfaces, or Icefaces
with a middle layer of CDI Managed Beans using application server auto generated JPA entities mapped to an RDBMS like Oracle - go
right ahead and design this monolithic segment of your system. JPA entities can still be mapped to DB Views that call complex
SQL queries or straight DB tables exposing data-points that web pages and backend methods utilize.
Wait, you can even use Skinny WAR file builds (no more than kilobytes in size) in conjunction with many databases on multiple
servers either RDBMS or NoSQL (like MongoDB). The design patterns you use can be many and diverse so that you have the flexibility
to scale both horizontally and vertically without dead-end alleys blocking your way.
even HTML5 on the client-side.
So you say you need SOA particularly microservices - JAXRS using the JSON-B and the new JSON-P
packages that are included in Java EE 8 make development of RESTful web services a breeze. You want to containerize your web services
than why not use Docker coupled with Kubernetes orchestration.
Java EE 8 also supports asynchronous communication both on the client and server. Better yet, never fret over security because
with Java EE Security API 1.0 Java EE 8 allows you to handle security issues across the entire framework in a consistent manner.
What about validation? This is still built into the bean layer with Bean Validation 2.0.
Coding thousands of lines in the weeds and having dependencies with every known open-source based technology
is not something you will need to worry about when using Java EE 8 - just focus on the business requirements and designing the most
maintenance free user friendly lean applications.
Modularity is now part of the new Java SE 9 code library that Java EE 8 requires. In Java SE 9 logically grouping classes in packages
that can further be a part of modules within a project significantly enhances reusability especially since these modules can also
be built separately using a build and dependency resolution tool like Gradle. These modules may also be distinct domain
isolated build artifacts that can be generated when needed and reused in other projects.
Domain-Driven Design bounded-contexts can also be easily enforced through the use of Java packages. High-level packages or modules could
reflect contexts of a particular domain like an online store. The packages could be purchase, ship, merchandise, and user all contexts
of the domain store. Internal to each package/context could be found sub-packages split by technical concern like view, controller, model,
and persistence. Each domain context Java package would have the same technically categorized sub-packages.
No matter what architectural design pattern is selected never over complicate the architecture to the point that the development
process is seriously hindered. Stay clear of
cargo cult programming, a
dogma driven approach inspired by a constrained herd-mentality perspective. Spring 5
and especially Spring Boot are a marvelous group
of technologies but always opt to use Java EE 8 or later instead of Spring MVC. Java EE's intrinsic MVC design pattern allows developers
to concentrate on the important accepts of their application instead of 'wiring' the MVC design pattern into their systems.
One size fits all technologies do not exist. Just because a technology is new does not negate the use of more seasoned approaches that might
still be used to solve complex challenges. Always attempt to isolate technologies that reduce developer complexity, enhance maintainability, and
meet the architectural requirements of the applications you will eventually field to production. Never pick the latest shiny tools off the 'shelf'
just because everyone else is reaching for them - research before you recommend and implement any technology strategy.
My Early 1999 - 2004 Trailblazing Applications and Concepts that Contributed to Many of Our Most Advanced Modern Technologies
HTML Editor - Direct Editing of HTML Document
RDML Editor - One of the First XML Databases
Spherex - Early Progenitor of NLBIS
NLBIS and it's Progenitor Applications
NLBIS - Manual & Autonomous Control
NLBIS - Record/Playback
In 2006 NLBIS was the first Multiagent Multidimensional-Domain Online Reasoning System.
With NLBIS a knowledge base designer can create multiple worlds with intended interpretations using the precepts of
propositional calculus fused to object-oriented representations.
The ontology of a NLBIS world [the axiomatization of domain(s)] is specified by the knowledge base designer
through the use of the Hypervisor-Brain (admin layer) that writes or updates the ontologies to RDML (an XML schema) files.
NLBIS explicitly represents the state-space for a domain with state-feature pairs that specify the resulting desired state
after carrying out actions (the act of transitioning to the desired state) that are tied to a specific transition state's
features. Once NLBIS nodes resolve to their desired state this desired state becomes their current state.
The domains that are the NLBIS multidimentional representation of worlds created by the knowledge base designer also
have there own deterministic planner assimilated into the highest level Universe view deterministic planner of NLBIS.
Each node runs in its own asychronous distributed process within a domain that runs within its own
asynchronous distributed process with all of them running concurrently in NLBIS.
NLBIS SoS from my BlueNova Software
The overriding objective of architecting, developing,
and implementing the NLBIS was to develop a dynamic distributed state-based
asynchronous aware system-of-system framework that was generically independent
of its implementation.
B. Unique problem characteristics
Architecting a system-of-system framework that is both aware of it's
internal and external environment and able to responded to predefined
deterministic state changes over the full spectrum of internal and external
objects that NLBIS monitors. No other systems currently exist that solve
the problem of deterministic state-based adaptation via external and
internally monitored state change stimuli in a pub/sub asynchronous
proxy payload messaging communication environment.
C. Disadvantages or limitation of prior solutions
All prior attempts at state-based type systems have not been generic,
where not extensible, where not aware of their internal and external
environments, lacked a coherent object model framework for developing
management layers, did not have a failsafe backup pub/sub asynchronous
communication environment, and where essentially not designed in a
NLBIS should provide for the complete control, monitoring, feedback, and interpretation of all systems.
It should provide a user friendly GUI that may be used for configuration, direct control, monitoring, feedback and hence be termed the Management Console.
The Management Console should have a tabbed display whereby the user may navigate through the different layers of the NLBIS.
The Management Console will have a Dimensional Selection splash screen and the following tabs Master, Systems, Components, Commanders, Commands, Remote, Server, Database, Language, Master Servants, System Servants, Component Servants, Master Display, System Display, Component Display, Record/Playback, and any other tabs deemed necessary.
NLBIS should allow the user(s) to record and playback of C++, Java, and other applications coded in object-oriented programming languages through the use of NLBIS.
NLBIS should not require the user to edit any script(s) within a text editor but provide complete configuration facilities within the NLBIS GUI environment.
A manual direct mode of operation over in real time should be incorporated into the basic NLBIS functionality and easily configured, controlled, and adjusted within the NLBIS Management Console.
NLBIS should read relevant data points from various data sources and utilize those data points accordingly.
Preemptive State Control
Within a system such has NLBIS that monitors and controls all slave systems within process it would be quite
feasible to not only monitor slave system states and inhibit them from moving outside desired states but
preemptively move slave systems from their current state1 to current state2 based upon analysis of well defined
external & internal stimuli affecting the slave systems. Essentially, a probability of a slave system moving
from one current state to another current state could be determined based upon historical past metrics related
to external & internal stimuli affecting the slave system. This would add another layer of intelligence to systems
like NLBIS that already deterministically control their system-of-systems slaves to adhere to desired states.
These other states might become a subset of desired states possibly called preemptive states.
Far too often multiple third party API's are used in the development of a system simply because of the
seemingly relevant business expedient of reducing the development timeline. Utilizing a 'glue API' that
doesn't provide a significant technological advantage over a far simpler self developed construct may
increase the likelihood of failure within a system. It must be remembered that the introduction of any
code and most of all an entire code library (API) into a system will affect a system in many ways - some
of those effects may be negative. State Stability Theory is relevant in describing not only the effects
of 1...n sub-systems linked to a network but also 1...n code libraries utilized within a system. In effect,
each and every code library utilized within a system becomes a point of failure that is much more difficult
to debug and maintain. The savings gleaned from utilizing a code library should be compared to the increased
probability that maintenance of an entire system increases with the introduction of each library.
Desired states of a system are highly dependent upon the states of the namespace delimited system components
some of which are also libraries, their associated objects, and the objects associated methods or functions.
Therefore the benefits obtained from the utilization of any library should outweigh the potential disadvantages
of the introduction of an element into a system that may have other indeterminant overall system state effects,
increased maintenence costs, increased overall system footprint, and the time expended on developers learning
the new library. Nothing above suggests that libraries shouldn't be utilized only that there utilization should
first be subjected to a cost benefit analysis. In some cases development of comperable functionality provided
by a library would entail significant effort and time on the part of a development team. It is in these cases
that a library might provide advantages that far outweigh its effect upon a system. In fact, if the library
state effects can be isolated and compensated for within the system with minimal effort than the usage of the
library is advantageous.
Unfortunately, in far too many cases a library is used simply because it provides a limited degree of
functionality that the developer could have more simply coded but due to developer inexperience, unrealistic
management imposed time constraints, simple laziness on the part of the developer, or any number of other
reasons a library is utilized whereby only a small fraction of its capability is utilized. These are the
'red flag' cases that expose a system to unpredictable state effects precipitated by the library, an increased
system footprint, increased maintenance costs due to the libraries indeterminate state effects on the system
and other libraries (my State Stability Theory). Essentially, only use a library when the benefits far outweigh
the risks and when that is the case make it a point to completely understand the libraries effects on the
stability of the system and where possible compensate for these state stability effects.
When something starts to seem too complex it probably is - simplicity equates to elegance and this is
natures check on instability. Simplify, to the point of intellectual pain.
Represents the entire functional or physical component.
Accounts for all AbstractSystem objects.
Maintains configuration information on all AbstractSystems in an XML document.
If an AbstractSystem 'dies' creates a new type of AbstractSystem to replace
the one that expired from the information for the particular AbstractSystem found within the above-mentioned
XML configuration document.
Represents a well-defined sub-system of the entire functional or physical component.
Every AbstractSystem has a collection of AbstractComponents and Commander objects.
Accounts for all Commander objects through its TSpace server.
Checks the Commander objects connection status through TSpace server.
Checks the Commander objects progress through TSpace server.
Check for Commander connections that fail while commands are being made and
respond accordingly (analogous to transactions in a database).
TSpace server recoups resources once a Commander connection terminates.
Represents the wrapper object of Command objects (command/control sequences) destined for
one or many SystemSpaces.
Listens for current state change events thrown by an instance of CurrentStateObserver.
Observes changes in a components current state.
When a change occurs in the current state of the component that the CurrentStateObserver
has been assigned to observe the CurrentStateObserver throws a current state change event.
Represents the actual command/control sequence.
Is an action that the AbstractBridgeState takes for each Command that is extracted when it
unwraps all the Command objects found within the Commander object that it was listening for on a SystemSpace.
Represents a well-defined measurable characteristic/component. Must have a metric associated
with it such as in the case of environment power hertz (Hz) would be a good example.
Composed of an AbstractCurrentState, AbstractBridgeState and AbstractDesiredState object.
The resting state of a component.
The resting state should be defined within a range of metric values relevant for the component.
Acts as a bridge between the current state and the desired state in those cases when the
current state value is not the desired value that is desired for the component.
The desired state of a component representing a state that the component is desired
to be in and thus every means is made by the component to reach this state.
Must be able to determine through an event when this state starts life and ends life (basically
when the class is instantiated and loses scope and/or is garbage collected).