Spryker Systems Tech Deck

Transcription

E-commerce platform for
customer-centric, agile
market leaders
Summary
Established commerce software developed within real-world projects
Agile framework approach, highly relevant for ambitious market players and
non-standard digital business models
Best practices of 100+ technology implementations went into Spryker’s
development with a focus on
agility
speed
innovation
business intelligence
2015 Spryker Systems GmbH / About Spryker
2
1. Our Story
2. The market and how we fit in
3. Software architecture
4. Spryker’s technology concept
5. Delivery
3
Our Story
Spryker’s technological roots – known
as “Alice and Bob” and “Yves and Zed” –
are Rocket Internet’s and Project A’s
in-house software solutions designed
to meet the demands of ambitious and
disruptive commerce projects.
The requirements of such projects led
to the creation of the internal software
as there was no appropriate technology
available in the market.
In November 2014 Spryker was
founded to offer the architecture to
industry clients.
Predecessors of Spryker’s technology are
implemented in 100+ commerce companies
Category leader for
fashion in Brazil
Largest furniture shopping
club in Europe
B2B-webshop with
complex business logics
European online tire dealer
and car accessories shop
startup with an innovative
online wine concept
Europe‘s leading supplier
for intelligent nutrition
4
Key Technical Learnings
Full-page caching
Anti-pattern: increases complexity, reduces personalization
Website draws from database
Bad performance & scalability
Unnecessary code components & features are interwoven throughout the code base
"Fight the framework" kills productivity
Entity Attribute Value (EAV) model
Hard to maintain, slow DB queries, no consistency
Monolithic approach with complex codebase
Long deployment cycles and onboarding time for new developers
5
Spryker solves a lot of common issues
Common issued of shop software
Solutions integrated in Spryker
Full-page cache
Separation of frontend and backend
Website draws from database
Frontend draws from Key Value Storage
Unnecessary code components & features
Lean code base and modular features
Entity Attribute Value (EAV) model
Extend DB Schema + JSON values
Monolithic approach
Modular monolith
6
1. Our Story
5. Delivery
7
Gartner’s concept of bi-modal IT
How Gartner describes the Enterprise IT market:
CEOs, CIOs and CTOs are frustrated with poor IT team performance in a competitive,
fast-changing market environment
Rhey're starting to build more agile teams, separate from traditional IT, to deliver
innovations with short time-to-market cycles
These teams cannot rely on legacy systems to solve next-generation challenges
MODE 1
Traditional and reliable
Waterfall approach, slow, long term
IT-centric culture
MODE 2
Agile and exploratory
Continuous, empirical approach
Customer-centric & testing culture
8
E-Commerce Technology matures
1st Generation
ERP-focused setup
E-commerce =
additional sales channel
PIM
CRM
OMS ERP
CMS
…
Shop
1995 - 2002
2nd Generation
Features move into Shop
3rd Generation
Features move out in Ecosystem
E-commerce =
part of an ecosystem
E-commerce =
new business model
ERP
PIM
CRM
Shop OMS
CMS
…
2003 - 2013
PIM
CRM
+ channels
+ devices
ERP
Shop
OMS
+ complexity
+ content
…
CMS
+ uncertainty
2014 +
9
Enabling tomorrow’s technology leaders
Degree of Individualization
In-House Solutions
Traditional retail
companies:
standard sales processes
for e-commerce without
individualization
FRAMEWORK
Standard Software
Market leaders risk
using untested in-house
solutions in order to
become technology
leaders
Technology as Value Driver
10
Spryker Use Cases (examples)
Online Pure Players
Category Leaders
Digital retailers with
strong customer focus
Ambitious market players
claiming a market niche
High revenue volume /
high growth
Highly competitive
approach and need for
cutting edge technology
Strong online competence
needed in a competitive
market environment
Be ahead of the market
Unique Models
Non-standard business
models, e.g. marketplace,
subscription, customized
products, B2B, complex
business processes, …
Including digital models for
banks, insurances, IoT, …
Internationalization
11
Why standard software is often no option
There is no standard software for a non-standard business.
Hard to remove components from off-the-shelf solutions
e.g. monolithic Magento system
Hard to integrate into not supported environments
e.g. closed sourced environments & Hybris
Hard to create new features
e.g. can’t run full stack on developer machine at
Demandware and other SaaS solutions
Retailers want control
over their destiny. They need to
be able to make changes quicker
and innovate faster. By bringing
the e-commerce technology inhouse they will be better able to
do this — versus being beholden
to a legacy platform.
Internet Retailer, July 2015
Standard software is for configuration, not for development
à use a framework to build something new and customized
12
1. Our Story
5. Delivery
13
Technology Summary
Framework approach
Modular monolith
Frontend / Backend separation
Symfony / Silex based PHP Application
Developer friendly
14
Building Blocks - principles
Spryker is good software craftsmanship:
SOLID - CLEAN CODE – SEPARATION OF CONCERNS
15
Software Principles & Patterns
SOLID: Single Responsibility Principle
There should never be more than one
reason for a class to change
Default principle for each class is
defined in Spryker
Single responsibility principle is
applied on bundle, class, and method
level
Example : facade classes represent
the internal API of a bundle and the
only point of access to a bundle
Facades are flat and stateless classes
- their only responsibility is to
orchestrate the incoming requests
to the business logic implemented in
the bundle
16
SOLID: Open Closed Principle
A module should be open for extension
but closed for modification
Modules are written so that they can be
extended without being modified
Implemented through plugins in
Spryker
Example: deliver customization & add
complex configuration in the sales flow
Example of possible implementations
for ShipmentMethodAvailabilityPluginI
nterface : DHLExpressPlugin /
DHLStandardPlugin
Each of these plugins must
implement ShipmentMethodAvailabilityPluginInterface
17
SOLID: Interface Segregation Principle
Many client specific interfaces are
better than one general interface
In Spryker this is used for facades
In order to substitute a bundle
with a new one, its facade must
contain the same operations so
that it doesn’t break the contract
established with other bundles
Each bundle ships with a set of
interfaces for facades of the
required bundles
18
SOLID: Dependency Inversion Principle
Depend upon Abstractions. Do not
depend upon concretions
High level modules shouldn't know
implementation details about
other modules, they should depend
only on abstractions
Dependency container: one for each
layer in a bundle
The dependency container is IDE
friendly php code, no hassle with
foreign structures like yaml or xml
Dependency provider: one for each
bundle
19
Factory & Locator Pattern
Factories are used to instantiate new
classes inside a bundle
allows for different implementations
on core, project & store level
Locators used to access other bundles
allows for different implementations
on core, project & store level
decreases dependency between
bundles
20
Object Relational Mapper Pattern
ORM is used to abstract the
database access
Allows for different databases
No raw SQL in any layer
Queries are returned un-terminated,
so that the client can add restrictions
(limit, offset) and can choose how to
terminate (count, find, findAll)
QueryContainer holds all queries for
the current bundle
Can connect to other bundles to
create cross bundle DB joins
21
Building Blocks - technologies
Spryker uses conservative state of the art technologies
22
Technology architecture
23
Technology architecture - Frontend
24
Technology architecture - Frontend
PERFORMANCE: lightweight application, no
business processes, no fullpage cache, data pushed
to key value storage, 50 MS execution speed
SCALABILITY: almost infinitely scalable – because
of absent bottlenecks
EXECUTION: continuous deployment enabled, no
waterfall process, developer-friendly, simple code
FEATURES: cart, checkout, user management,
catalog w/full text search & facet filters, static pages
25
Technology architecture - Backend
26
Technology architecture - Backend
BUSINESS LOGIC: handles complex
business processes, infinitely scalable
DATA MGMT: communication hub
INTEGRATE: external providers like
Payment, Logistic, PIM, …
FEATURES: e.g. admin GUI, product
management, content management,
discounts, order management, ...
ORDER MGMT: as part of the shop,
separation of concerns possible, state
machine & fully automated
27
Technology architecture – BI – Draft
28
Technology architecture – BI – Draft
FULLY INTEGRATED: Spryker Intelligence as part of
the shop system to prevent loss of data and ensure full
data insight for both IT team and business user
SINGLE POINT OF TRUTH: all internal & external
(e.g. CRM, social media, email) data stored in one place
SPEED: KPIs and tracking can be set up quickly to
launch and track new Marketing campaigns effectively
DATALAKE: no storage according to schema = flexible
analysis of data as needed today and in the future
EXECUTION: allows for sophisticated personalization
29
Spryker Intelligence - Draft
ZED
YVES
external data
(tracking, CRM, …)
events
and logs
internal data
services
(personalization,
trend analysis, …)
events and logs
diverse data
real-time
r/w
DATA
PIPELINE
e.g. Kafka
rea
d
connectors
(Salesforce, Zendesk, Emarsys, …)
archive
batch
processing
via
connector
export
internal and external
systems
e.g. CRM, Social Media,
email marketing, ELK
DWH
DATA LAKE
DATAHUB
e.g. HDFS, S3
30
1. Our Story
5. Delivery
31
Scaling (implementation example)
Yves load-balancer
read
Yves
phpApp
Yves
phpApp
Yves
phpApp
Zed load-balancer
Zed
phpApp
read / write
read / write
DB
Elastic
search
Allows for rolling
deployment + Zero
Downtime
scale
read
Zed Main
phpApp*
Redis
Horizontal + vertical
scaling enabled
DB / Redis /
Elasticsearch as high
available services
scale
Master-master
or master-slave
configuration
write
*Zed main server only:
run cronjobs and post
deployment hooks
Sample infrastructure
provided via saltstack
templates
32
Spryker Bundles
Acl
Country
Oms
Search
Auth
Discount
Payment
Session
Availability
Distributor
Price
Shipment
Cart
Glossary
Product
Stock
Catalog
Invoice
Product
Category
Storage
Checkout
Item
Grouper
Product
Option
Url
CMS
Locale
Queue
User
Customer
Mail
Sales
Wishlist
All important features:
Spryker comes with
100+ bundles
Easy and fast updates:
each bundle has its own
versioning
Consistent: each
bundle has the same
basic architecture
Flexible & adaptable:
bundle dependencies
are reduced to a
minimum
33
Spryker Bundles
Acl
Country
Oms
Search
Auth
Discount
Payment
Session
Availability
Distributor
Price
Shipment
Cart
Glossary
Product
Stock
Catalog
Invoice
Product
Category
Storage
Checkout
Item
Grouper
Product
Option
Url
CMS
Locale
Queue
User
Customer
Mail
Sales
Wishlist
34
Bundle Dependency Management
AGILITY: minimal dependencies between
bundles, dependency management via
composer
LEAN SETUP: only include needed
bundles in project – keeps complexity as
low as possible
VERSIONING: upgrades on bundle level
- Efficient: only needed bundles
- Fast: quicker updates available where
needed, no waiting for next version
- Simple: no stiff and complex upgrading
of entire framework
35
Bundle Dependency Management
How dependencies are programmed
What the workflow looks like
checkout
bundle
checkout
bundle
availability – checkout
connector bundle
product
bundle
stock
bundle
availability
bundle
OMS
bundle
product
bundle
stock
bundle
availability
bundle
OMS
bundle
availability – cart
connector bundle
cart
bundle
cart
bundle
This way, dependencies are always kept to a minimum and the setup stays agile
36
Spryker bundles concept
Bundles = functional units, e.g. cart, checkout, product
Each bundle consists of up to 4 layers
Intersection of layer and bundle = box
PRESENTATION LAYER: templates for Zed admin gui
COMMUNICATIONS LAYER: controllers, UI-elements and plugins
BUSINESS LAYER: business and persistence logic
PERSISTENCE LAYER: (SQL) queries, entities and database schema
37
Presentation Layer
This layer holds all templates including all html, css and javascript
content
We separate presentation & logic
We use semantic CSS to get a uniform look and feel
PRESENTATION LAYER
COMMUNICATIONS LAYER
BUSINESS LAYER
PERSISTENCE LAYER
Technology
Purpose
Twig
Templating Engine
GulpJS
Frontend Development System
38
Communication Layer
This layer is a bridge between the presentation layer and the
external world (http request, cli-call, cronjob, other bundles,
etc.)
PRESENTATION LAYER
BUSINESS LAYER
PERSISTENCE LAYER
Elements
Parts and purpose
Locatable
Controller
Normal controller with actions. Responsible to retrieve request-data, delegate to
business layer and provide content to the presentation layer
yes
Forms
A class holds the constraints and provides the data. The layout and field-types are
defined in twig-template
no
Grids
A class configures the columns and provides the data. The layout and field-types are
defined in twig-template. A grid needs dedicated controller-action to send the jsondata
no
Plugins
Plugins are classes which are used to loosly couple bundles (see dependency system)
yes
Dependency
Container
Here all classes are wired-up
no
39
Business Layer
This layer holds all business logic
PRESENTATION LAYER
BUSINESS LAYER
PERSISTENCE LAYER
Elements
Parts and purpose
Locatable
Facade
A facade represents the entry point into the business layer. We could also see it as
internal API
This is a implementation of the facade-pattern
yes
Settings
Holds all settings which are needed by a bundle
no
Models
The models hold the business logic
no
Dependency
Container
Here all classes are wired-up
no
40
Persistence Layer
Here there are all entities, queries and the schema
PRESENTATION LAYER
BUSINESS LAYER
PERSISTENCE LAYER
Elements
Parts and purpose
Locatable
Query
Container
The QueryContainer contains of all queries and returns them un-terminated. This class'
responsibility is to hide the structure of the schema and to enable reuse of queries
yes
Entities
An entity represents a domain object, like a 'customer' or a 'cms-page’
This is an implementation of the active record pattern
yes
Queries
The query-classes contain queries which are often used, which is useful to avoid
QueryContainer to get too big
no
Schema
Every bundle ships with a piece of the big schema which is defined in XML
no
41
Spryker bundles concept
Bundles = functional units, e.g. cart, checkout, product
Each bundle consists of up to 4 layers
Intersection of layer and bundle = box
PRESENTATION LAYER
BUSINESS LAYER
CART
BUNDLE
CHECKOUT
BUNDLE
PRODUCT
BUNDLE
PERSISTENCE LAYER
42
Store Concept
Stores are separated business units – e.g. by country
can serve multiple languages / locales per store
only one currency per store
separate product and order data per store
separate logic e.g. tax-calculator for Switzerland
replication / distribution of data across stores possible
stores share the same codebase
DB
Store DE
€
Distribute data
via queue
DB
Store CH
CHF
DB
Store US
$
43
BUSINESS LAYER
PERSISTENCE LAYER
STORE LEVEL
PROJECT LEVEL
PRESENTATION LAYER
CORE LEVEL
Separated core, project & localized code
US, DE, UK, FR, CA, …
client implementation
Spryker bundles
44
Separated core, project & localized code
CORE
product
bundle
cart
bundle
PROJECT
product
bundle
cart
bundle
STORE
Implementation example of the three levels
Extract of implemented core bundles
Custom projects added to adapted core bundles
Custom bundles for specific stores / localized shops
productDE
bundle
productFR
bundle
Factories allow to extend all classes.
Extension of the dependency
container allows to replace any class.
stock
bundle
MySpecial1
bundle
MySpecial2
bundle
MySpecial2FR
bundle
45
How to extend / integrate Spryker
order
management
state machine
events
state machine
commands
ERP
custom
bundle
custom
API
CRM
product
bundle
Spryker
API
PIM
Spryker
API
ZED
SPRYKER IN USE:
Integrate with external systems
via state machine commands
Introduce new bundles with
provided Spryker architectural
layout
Use and extend API of existing
bundles on project and store
level
Everything is replaceable by
consequent use of dependency
containers and Interfaces
External services use REST API
46
Order Management in Spryker
Other Systems
Shop
Spryker
(optional w/ Spryker)
ERP
order
Shop
(recommended w/ Spryker)
ERP
= WMS
payment
pick &
pack
shi
p
return
refund
reality Shop and ERP: black box
with high potential for errors
Spryker allows for separation of
concerns, order processed in shop
47
Process model design / State machines
Conditions
waiting for
capture
Event: onEnter
Command: captureAmount
Condition: CaptureCondition
new
<<manual>> Button on screen)
capture
failure
invoice
created
capture
success
Event: onEnter
Event: Timeout 14days
clarify
reminder
Event: Payment received
waiting for
payment
Manual
waiting for
capture
Event: PaymentReceived
payment
received
Command: Initiate fullfillment
fulfillment
initialized
manual
capture
failure
manual
capture
success
48
Screenshots / Images available
separately as well as state
machine demo and source code
1. Our Story
5. Delivery
50
Spryker delivery contents
GIT repositories: all bundles as separate components
Infrastructure: deployment templates via saltstack
Demo-shop via Developer-VM: full stack development
shop template with all components
Spryker Academy: access to documentation and
project controlling templates
51
Security
Faster security patches through individual bundle upgrades
Spryker is always compatible with latest 3rd party tools &
libraries (e.g. Symfony)
Latest PHP Version is always supported
Frontend / Backend separation provides extra security
Platform agnostic (Webserver, DB, KV-Storage, …)
52
System Requirements
Spryker makes no assumptions about external systems...
...but comes ready with the right implementations
Item
Requirements
Recommended
Webserver
Any PHP enabled Webserver
Php-fpm with nginx
KV Storage
Any KV-Storage with Set, Get, Multiget
Redis
Search
Search Engine with faceting
Elasticsearch
DB
DB supported by Propel
(MySQL, PostgreSQL, Oracle, MSSQL)
PostgresSQL &
MySQL
OS
Any OS running a Webserver
Linux
53
What makes development with Spryker so fast?
Architectural decisions are provided by the framework
Best practices from over 200 implementations included in
the technology
Consequent de-coupling of bundles supports fast iterations
Full IDE auto-completion
“No magic methods” enable easy debugging
Complete stack on developer laptop
Coherent architecture (Frontend, Backend, Extensions)
54
Spryker Customers Characteristics
Customer-centric
Decision-making focused on creating value for customer
Business model has new and innovative components
Technology as Value Driver
Continuous delivery, highly competitive execution speed for new features
Differentiate from competitors partially through technology
Ambitious
High-volume and high-growth online and omni-channel retailers
Goal to be a category leader, grow internationally or disrupt an industry
55
Why Spryker is a framework, not an application
Frameworks … treat extensions as first class citizens
… result in a clean codebase
… allow for individual upgrade paths of single components
FRAMEWORK approach versus APPLICATION approach
Shop
Shop
Cart
Products
Cart
Extension
Products
Extension
Framework
Application
56
Yves client layer
YVES
Controller, Themes
CLIENT
CART CLIENT
STUB
SEARCH API
STORAGE API
RPC
JSON
Query
Redis
Protocol
GATEWAY
ZED backend
SEARCH
STORAGE
Yves only consists of
templates, controllers,
service providers
Possible to build another
Yves with another
framework and still use
Spryker
Client is core functionality
for the shop frontend
Client acts as as a façade
and delegates calls to Zed,
Search and Storage
57
Spryker enables micro-services
YVES
Catalog
YVES
Cart
Merchant
Portal
RPC
RPC
RPC
ZED
Catalog
ZED
OMS
Postgres DB
MySQL DB
ERP
ZED
B2B
Framework approach
allows for independent
services
Decoupled bundles and
defined APIs make
integration and separation
into services easy
Legacy DB
58
You can not solve 21st generation
ecommerce problems with 20th
century technology.
59

Spryker Systems Tech Deck

Transcription

Similar documents

Flyer Minting - Sack und Kiesselbach

QUICK INSTALLATION GUIDE SPECIFICATIONS

Scooter Soundboards - WilTec Wildanger Technik GmbH

TB-CDP02-TX/RX

V2_Programm_Bremerhaven__englisch_2.

oscar - akasol eV

PDF - privacyGUARD

What does it measure? The Visioscan® VC 98 USB is a special UVA

960529 Walther Faltsysteme UM WA 15 JR en.cdr

Bulletin Vol 17 Nr 5 - October 2011

Goettsche L. (ed.) T..