Analyzing a project’s requirements, selecting a vendor based on them and deciding on the product mix is only the first step towards building a solution. Even though functional requirements are a focal point at this stage, non-functional requirements such as performance, availability and security also play a major role when optimizing a solution in real life. In order to meet these needs the solutions architecture team, comprising of parties from both the vendor and the customer, need to factor in certain activities such as performance testing, capacity planning and deployment and security validation. In this session Shiro will look at these activities from a solutions perspective by sharing their experiences to make sure your project is put through the necessary steps that lead to success.

1. Building your Deployment
Architecture through Requirements,
Capacity Planning and Performance
Tes=ng
Shiroshica Kula=lake
Associate Director / Solu0ons Architect
WSO2

2. Agenda
• Determining the Solu0on Architecture
• Determining the ini0al Deployment Architecture
• Taking security into considera0on
• Considering capaci0es
• Tuning and Tes0ng the deployment
• Key take aways

3. Business Requirement

4. Determining the Solu=on Architecture

5. Moulding the Solu=ons Architecture
• What are the overall business requirements ?
• What are the func0onal components ?
• What are the support services needed ?
– User management or IAM
– Data virtualiza0on
• From the func0onal components which parts are already
there ?
– Message Broker
– IAM

6. Breaking down the requirement to Func=onal Units

7. Mapping the PlaEorm Products

8. Determining the Deployment Architecture

9. Func=onal aspects which would affect a
Deployment
• Which components would be accessed by internal users /
systems ?
• Which components would be accessed by external users /
systems ?
• Which components need to access external services ?
– Cloud services

10. Deployment Diagram with Func=onal Needs

11. Non-func=onal aspects which would affect a
Deployment
• Which components need to be deployed in a distributed
manner ?
• Which components would scale similarly / differently ?
• Which components need to be highly available ?
• How would high availability be handled ?
– In the same Data Centre
– Across mul0ple Data Centres

12. Deployment Diagram with Non-Func=onal Needs

13. PaIerns and Reference Architectures
• Is there a reference architecture defined for similar cases ?
• Is there a paOern catalog for deployment op0ons ?

14. Deployment Diagram with Non-Func=onal Needs

15. Determining the Security Architecture

16. Security Aspects that maIer
• Which components would be accessing which data ?
• Which data needs to be secure ?
• Which components should have restricted access and how ?
• What are the user groupings that need to be thought of ?
• Is there overlap of visibility across user groups ?
• What are the Authen0ca0on, Authoriza0on needs ?
• How are security tokens stored ?
• What security informa0on need to be propagated
southbound ?

17. Security Flows to consider - API-M

18. Security Flows to consider - Applica=ons & Users

19. Deployment Architecture with Security Considera=ons

20. Capacity Planning

21. Factors Affec=ng Sizing
• How many requests would go through the solu0on ?
– At entry point
– Across each component
• How much of load would be handled at each component ?
– Payload size
– Transforma0on load
– Concurrent users and concurrent sessions
• How many instances of each component is needed ?
– To handle the load
– To handle high availability

22. Determining the Flows and Load
• API-M
– 1500 TPS - External API
Calls
– 500 TPS - Internal API Calls
– 250 Concurrent Users
• Integra0on
– 1250 TPS - ESB
– 250 TPS - BPS

23. Deployment Architecture with Sizing Considera=ons

24. Figuring out the Hardware
• What’s the minimal hardware requirement for a type of
instance ?
– Processing power and memory
– Disk requirements
• What’s the data load going to look like ?
– Opera0onal data
– Analy0cs
– Support data - user stores, registry etc.
• Virtualized Machine, Container ?
• On premise or Cloud hosted ?

25. Tuning and Tes=ng the Deployment

26. Tuning the Deployment
• What are the op0mal product seZngs ?
• What are the features most used ?
• Which features are not really needed ?
• What is the underlying hardware capability ?

27. Tuning the Deployment

28. Tes=ng the Deployment
• What is the load which will break the solu0on ?
– Load tes0ng
– Stability tes0ng
• Are the required latencies achieved ?
– Performance tes0ng
• Will there be any accumulated inefficiencies over 0me ?
– Long running tests

29. Tes=ng the Deployment

30. Key Takeaways

31. What’s Important
• Know your business requirement really well
• Iden0fy func0onal as well as non-func0onal factors which
would affect the solu0on
• Security is a first level ci0zen
• Reuse components when possible
– New elements
– Exis0ng elements
• Edge cases do maOer
• You are not alone - don’t reinvent the wheel
• Test - not just once but several 0mes ! and keep on tuning

32. Thank You!
#WSO2ConEU
Share your feedback for this session
wso2con.com/app